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Preface 


* 


I  came  to  AFIT  interested  in  compiler  writing  and 
programming  languages.  This  thesis  effort  allowed  me  to 
combine  those  interests  into  a  very  interesting  and 
self-satisfying  project,  a  compiler  and  interpreter  for  a 
subset  of  the  Ada  programming. 

I  would  like  to  thank  Maj.  Roie  Black  for  proposing 
this  project  to  me  and  introducing  me  to  the  Ada 
programming  language.  I  would  also  like  to  thank  my 
advisor,  Capt.  Pat  Lawlis,  for  all  her  help  and  guidance 
during  this  effort. 

Finally  1  must  thank  my  loving  wife  for  her  patience 
and  support  and  my  children  for  just  being  children  and 
making  me  laugh.  Without  their  support  and  love  this 
project  might  not  have  been  completed. 
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Abstract 
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This  document  describes  the  effort  involved  in  moving 
the  AdaO  compiler  and  interpreter  developed  by  Capt.  Scott 
E.  Ferguson  as  part  of  the  AFIT  syntax  directed  editor 
environment  from  a  microcomputer  to  the  VAX  11/780. 

As  part  of  this  effort  the  compiler  and  interpreter 
were  expanded  to  accept  a  larger  suset  of  Ada.  The 
compiler  and  interpreter  work  with  an  abstract  syntax 
representation  of  a  computer  program  produced  by  the  syntax 
directed  editor.  This  abstract  representation,  which  is 
guaranteed  to  be  syntactically  correct,  makes  the  compiler 
much  easier  to  write  and  understand.  The  compiler  in  a 
top-down  compiler  but  no  backtracking  is  needed  since  the 
program  is  known  to  be  syntactically  correct.  The 
interpreter  is  able  to  use  the  abstract  representation  to 
give  the  user  an  interactive  display  of  the  program  during 
execution. 

Designs  to  allow  overloading  of  names  and  operators, 
and  passing  parameters  to  subprograms  are  also  presented. 
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INTRODUCTION 


1.0  INTRODUCTION 

Ada  is  the  new  computer  programming  language 
developed  by  the  Department  of  Defense.  Motivated  by 
desires  for  increased  productivity  and  lower  costs, 
requirements  for  a  programming  support  environment  were 
also  developed  (Ref  8) .  This  thesis  is  one  of  a  pair  in  a 
continuing  effort  to  develop  such  an  environment.  This 
effort  is  based  on  a  prototype  environment  developed  by 
Capt  Scott  Ferguson  (Ref  9) .  His  effort  is  centered 
around  a  syntax  directed  editor  which  creates  an  abstract 
syntax  representation  of  a  program  which  the  othef  tools 
in  the  support  environment  work  with.  This  effort 
continues  the  development  of  the  compiler  and  interpreter 
within  this  environment. 

1.1  PRIMARY  OBJECTIVE 

The  principle  objective  of  this  thesis  effort  was  to 
continue  the  development  of  the  AFIT  Ada  programming 
support  environment  originally  developed  by  Scott  E. 
Ferguson.  This  involved  an  analysis  of  the  Ada 
programming  language  and  the  work  done  by  Ferguson.  This 
was  done  with  the  intent  of  moving  the  support  environment 
from  the  microprocessor  it  was  developed  on  to  the  VAX 
11/780  and  expanding  the  subset  of  Ada  that  it  would 
accept  and  compile. 
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Since  the  environment  included  several  basic 

tools,  the  ef tor*  divided  into  two  separate  but 

related  thesis  etf  .*■  The  basic  tools  included  in  the 

original  system  are  a  syntax  directed  editor,  a  program 
lister,  a  compiler  code  generator,  and  an  interpreter  to 
run  the  compiled  program.  This  document  describes  the 
effort  involved  in  getting  the  code  generator  and 
interpretfer  tools  of  the  support  environment  wc  „ng  on 
the  VAX  11/780  and  the  expansion  of  the  Ada  sv  ?t  the 
compiler  would  accept.  Also  included  is  brief 
discussion  of  the  other  tools  in  the  support  env.  jnment 
and  how  they  interface  with  the  compiler. 

1.1.1  SECONDARY  OBJECTIVES 

The  main  secondary  objective  was  to  enlarge  the 
subset  of  Ada  the  compiler  would  accept.  The  features  to 
be  added  are  new  data  types,  functions  and  some  new 
statement  forms.  Since  the  original  effort  was  named  the 
AdaO  compiler  by  Ferguson,  this  effort  was  called  the  Adal 
compiler. 

The  other  secondary  objective  was  to  design 

algorithms  and  data  structures  to  support  a  later 

implementation  of  overloading  of  names  and  operators, 
parameters  for  functions  and  procedures,  packages,  and 
user  defined  data  types  into  the  expanded  Adal  compiler. 
This  objective  was  left  as  designing  the  algorithms  and 
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data  structures  since  many  problems  had  to  be  solved 
before  any  of  the  algorithms  could  be  implemented.  Time 
restrictions  placed  on  the  thesis  effort  rather  than 
complexity  of  the  algorithms  was  the  main  consideration. 


1.2  BACKGROUND  OF  THE  ADAO  COMPILER 

The  current  AdaO  compiler  accepts  only  a  small  subset 
of  the  full  Ada  language.  Included  in  this  subset  are 
integer  variables,  parameter less  procedures,  integer 
arithmetic.  Boolean  expressions  involving  integer 
relations,  and  many  of  the  statement  forms  of  Ada.  The 
statement  forms  included  are  assignment,  procedure  calls, 
if  statement  and  while  loops.  The  Boolean  expressions 
included  are  integer  comparisons  and  the  Boolean  operators 
and,  or  ,  and  not. 

1.3  OVERVIEW  OF  THE  THESIS 

To  be  able  to  properly  discuss  improvements  to  the 
AdaO  compiler  and  support  environment  a  discussion  of  the 
features  of  Ada  itself  is  required.  Chapter  2  provides 
this  discussion  and  a  short  discussion  of  the  Adal  subset. 
Chapter  3  is  a  discussion  of  the  support  environment  and 
the  tools  as  currently  implemented.  These  tools  include  a 
syntax  directed  editor,  a  program  lister,  the  compiler, 
and  an  interpreter/run  time  mechanism.  Chapter  4  provides 
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a  more  detailed  discussion  of  the  current  Adal  compiler 
and  how  the  extensions  were  implemented.  Chapter  5 
provides  the  details  of  the  designs  done  for  this  thesis 
effort.  These  include  a  semantic  analyzer  to  handle  the 
resolution  of  overloaded  names  and  operators,  a  way  to 
handle  passing  of  parameters  that  will  allow  in  and  out 
parameters  and  not  be  limited  to  simple  types,  and  the 
data  structures  to  implement  user  defined  data  types  and 
allow  for  package  elaboration  and  inclusion.  Chapter  6 
describes  the  ultimate  goals  and  environment  of  the  Ada 
compiler.  Chapter  7  is  a  discussion  of  my  conclusions 
from  this  thesis  effort  and  my  recommendations  for  future 
work. 
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2.1  BACKGROUND  OF  ADA 

Ada  is  the  new  computer  programming  language 
developed  for  the  Department  of  Defense.  The  driving 
force  behind  its  development  is  the  the  rapidly  increasing 
cost  of  software,  both  new  and  modified.  These  increasing 
costs  are  further  amplified  by  the  fact  that'  many 
different  and  incompatible  computers  are  used  within  the 
Department  of  Defense.  These  differing  computers  have  led 
to  the  use  of  a  plethora  of  special  purpose  languages  to 
program  them. 

This  causes  problems  in  training  since  a  programmer 
may  need  to  learn  a  new  language  or  system  when  he  changes 
jobs.  This  also  causes  the  programmer  to  be  less 
efficient  until  he  comes  up  to  speed  under  the  new  system. 
In  fact  if  the  languages  are  different  enough  the 
programmer  may  have  to  begin  almost  at  square  one. 

This  also  means  that  a  routine  developed  for  one 
system  must  be  rewritten,  if  it  is  needed  on  a  different 
system.  Even  programs  written  in  high  level  languages, 
like  FORTRAN,  can  require  changes  to  work  on  different 
computers.  These  changes  can  be  quite  extensive  even  if 
both  computers  have  FORTRAN  compilers.  A  standardized 
language  and  working  environment,  as  Ada  is  intended  to 
provide,  could  help  to  reduce  or  even  eliminate  these 
problems.  One  study  estimates  the  savings  to  be  in  excess 
of  one  billion  dollars  per  year  (Ref  10) . 
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For  these  reasons  and  others  that  will  be  brought  out 
later,  the  Department  of  Defense  developed  criteria  for  a 
standard  and  universal  language.  The  search  for  this  new 
language  began  with  existing  computer  languages.  Several 
of  the  more  popular  languages  were  examined  and  each  was 
found  to  be  deficient  in  one  respect  or  another.  Since  no 
existing  language  could  be  used,  the  Department  of  Defense 
held  a  four  contractor  competitive  design  effort  to 
develop  the  new  language.  This  competition  resulted  in 
the  development  of  Ada. 

2.2  GOALS  OF  ADA 

The  main  goal  of  Ada  is  to  help  reduce  the  costs 
involved  in  writing  and  modifying  software.  This  goal  is 
to  be  attained  in  two  separate  but  interacting  ways.  The 
first  is  through  the  use  of  a  standard  language  that  has 
many  features  to  aid  the  programmer.  The  other  is  through 
a  standardized  working  environment.  The  requirements  for 
this  environment  are  laid  out  in  "STONEMAN,  Requirements 
for  Ada  Programming  Support  Environments"  Feb  1980.  The 
purpose  stated  for  the  support  environment  is  to  "support 
the  development  and  maintenance  of  Ada  applications 
software  through  its  life  cycle"  (Ref  8) .  The  syntax 
directed  editor  mentioned  earlier  could  be  one  of  these 
tools . 
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2.3  FEATURES  OF  ADA 

The  syntax  directed  environment  will  help  make  Ada 
more  popular  among  computer  programmers  but  the  many 
features  of  the  language  will  do  more  to  stimulate  its 
use.  Ada  has  many  interesting  features  several  of  which 
should  be  discussed.  These  features  are  packages, 
overloading,  tasks,  separate  compilation,  and 
universality. 


2.3.1  PACKAGES 

Packages  are  one  of  the  more  interesting  features 
included  in  Ada.  They  are  one  form  of  Ada  program  units. 
Their  intent  is  to  allow  the  specification  of  groups  of 
logically  related  entities.  Packages  are  allowed  to 
contain  their  own  data  structures  and  types,  and  the 
subroutines  to  manipulate  them.  The  pieces  of  a  package 
can  be  visible  to  an  outside  program,  invisible  to  it,  or 
a  combination  of  the  two. 

Their  intent  is  to  allow  another  programmer  to  use 
the  data  structures  and  types,  and  the  manipulating 
routines  declared  in  the  package  without  knowing  or  caring 
how  they  are  implemented.  Keeping  the  structure  of  a  data 
type  invisible  to  the  programmer,  even  though  the  type 
itself  is  visible,  is  intended  to  prevent  the  programmer 
from  directly  manipulating  the  data  which  can  create 
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problems  for  other  routines  in  the  package. 

One  benefit  of  this  is  a  programmer  can  write  and 
compile  the  package  once  and  make  it  available  for  use  by 
other  unrelated  programs.  After  the  package  is  written, 
its  users  need  not  care  how  the  data  is  stored  or 
manipulated  but  only  that  the  results  obtained  from  the 
package  are  correct.  Since  a  user  does  not  care  how  a 
package  is  implemented,  the  package  body  can  be  changed 
and  if  done  properly  the  change  will  not  affect  any  of  the 
programs  using  the  package. 

package  complex_arithmetic  is 

type  complex_number  is  private; 

function  "  +  "  (A,B  ;  complex_number ) 

return  complex_number ; 
function  "-"(A,B  :  complex_number) 

return  complex_number ; 
function  create_complex { R,  I  :  integer) 

return  complex_number ; 

private 

type  complex_number  is 
record 

real_part  :  integer; 
complex_part  ;  integer; 
end  record; 

end  complex; 

Figure  2-1.  Sample  Package  Declaration 

An  example  is  a  package  to  do  arithmetic  on  complex 
numbers.  The  data  type  used  for  the  complex  numbers  could 
be  a  record,  an  array,  or  even  a  linked  list.  This  type 
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could  be  changed  from  one  to  the  other  without  any  affect, 
except  possibly  execution  speed,  being  seen  by  any  user. 

A  sample  package  is  declaration  is  shown  in  figure  2-1. 

This  interface  of  the  package  is  all  the  user  needs 
to  see  and  know  about  the  package.  Declaring  the  type 
complex_number  as  private  means  the  user  can  declare 
variables  to  be  of  type  complex  but  must  use  the  functions 
provided  to  manipulate  them.  The  user  is  allowed  to  do 
assignment  and  membership  tests  (Ref  6:  7-6).  This 

package  exhibits  another  feature  of  Ada,  overloading. 

2.3.2  OVERLOADING 

Overloading  of  names  and  operators  another  feature  of 
interest  included  in  Ada.  Overloading,  as  defined  by  the 
Ada  standard,  is  a  relatively  new  concept.  Unlike  Pascal 
and  other  block  structured  languages  which  hide  previous 
declarations  of  a  name  when  the  name  is  redeclared,  a 
redeclaration  of  a  name  in  Ada  only  hides  previous 
declarations  of  the  name  which  are  of  the  same  type.  The 
idea  is  to  allow  one  name  or  symbol  to  have  several 
different  meanings  depending  on  the  context  of  its  use. 
To  be  valid  the  context  must  make  the  use  unambiguous.  If 
two  or  more  meanings  are  consistent  with  the  context  then 
the  use  is  erroneous  and  must  be  modified  in  some  way. 

In  the  previous  example  the  operators  "+"  and  are 
overloaded  to  allow  their  use  with  complex_numbers .  An 
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overloaded  operator  can  be  used  in  the  usual  manner.  For 
example  the  following  code  fragment  will  cause  two 
complex__numbers  to  be  added  using  the  "  +  "  operator  and  the 
result  assigned  to  another  complex_number . 

a,b,c  :  complex_number ; 
a  :  =  b  +  c  ; 

The  idea  is  to  make  programs  more  readable  and 
understandable  for  other  programmers.  In  other  languages 
the  addition  of  two  complex  numbers  would  have  to  be  done 
using  a  function  or  procedure  with  a  name  like 
complex_addition.  This  would  make  the  program  readable 
but  some  programmers  would  shorten  the  name  to  someless 
meaningful  mnemonic  like  comp_add. 

The  designers'  of  Ada  felt  that  the  "+"  operator 
could  have  meanings  other  than  standard  addition  with 
respect  to  non-standard  types  and  that  it  should  be 
allowed  to  express  that  meaning.  They  also  allow  a  user 
to  overload  and  hide  the  standard  meaning  of  these 
operators  if  they  wish  to  define  their  own  functions  to  do 
addition. 

2.3.3  TASKS 

Tasks  are  the  next  feature  of  interest  included  in 
Ada.  Since  Ada  is  intended  to  be  used  mainly  in  the  area 
of  embedded  computers  by  the  Department  of  Defense,  this 
feature  is  very  important.  These  embedded  computer 
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systems  usually  require  several  functions  or  processes  to 
be  performed  simultaneously.  Tasks  allow  the  programmer 
to  define  several  processes  and  allow  them  to  execute  in 
parallel  either  on  a  single  processor  or  on  multiple 
processors. 

Tasks  are  allowed  to  communicate  or  synchronize 
through  the  rendezvous  feature.  Since  tasking  can  be 
implemented  in  several  different  ways  the  Ada  standard 
says  that  any  program  that  depends  on  the  implementation 
is  erroneous. 

An  interesting  feature  of  tasks  is  that  they  can  be 
defined  as  a  type  and  used  in  data  declarations.  This 
allows  the  user  to  define  arrays  of  tasks,  records  that 
contain  tasks,  or  any  other  legal  use  of  a  data  type.  The 
task  type  is  limited  so  assignment  and  predefined 
comparison  are  not  allowed.  Examples  of  tasks  can  be 
found  in  the  Ada  Reference  Manual  (Ref  7:  9-20). 

2.3.4  SEPARATE  COMPILATION 

Separate  compilation  is  another  feature  of  interest. 
Separate  compilation  is  a  term  that  has  been  misused  in 
the  past.  Many  languages  have  claimed  to  allow  separate 
compilation  when  what  they  truly  did  was  independent 
compilation.  The  difference  lies  in  the  semantic  checking 
that  is  done. 
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Independent  compilation  allows  a  function  or 
procedure  to  be  compiled  independently  of  the  rest  of  the 
program.  The  idea  was  to  allow  a  function  or  procedure  to 
be  used  by  several  different  programs  and  eliminate  the 
need  for  each  to  compile  the  common  parts.  Though  this 
saves  time,  it  causes  other  problems  since  a  using  program 
can  misuse  an  external  function  and  still  compile 
correctly.  The  error  generated  on  execution  may  show  no 
relation  to  that  misuse  and  cause  the  programmer  to  waste 
valuable  time  debugging  the  problem. 

Separate  compilation  requires  that  all  semantic 
checks  be  done  as  if  the  separate  pieces  were  all  compiled 
together  as  one  unit.  This  requires  the  compiler  to  have 
the  specifications  of  those  pieces  available  when  they  are 
needed.  This  difference  is  pointed  out  quite  nicely  in  the 
preliminary  reference  manual  (Ref  7:  10-1). 

2.3.5  UNIVERSALITY  AND  STANDARDIZATION 

Universality  is  the  final  feature  and  perhaps  the  one 
with  the  most  promise  for  helping  reduce  the  costs  of 
software.  This  feature  is  being  enforced  by  the 
Department  of  Defense.  Any  Ada  compiler  must  pass  a 
series  of  validation  tests  to  ensure  it  is  neither  a 
subset  compiler  nor  a  superset  compiler.  Only  after  it 
passes  these  tests  is  it  allowed  to  be  called  an  Ada 
compiler.  An  exception  to  this  is  allowed  for  any  subset 
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compiler  that  is  still  in  the  development  stage  and 
eventually  will  become  a  full  Ada  compiler. 

This  standardization  should  help  reduce  the 
retraining  problem  encountered  when  a  programmer  changes 
jobs.  Since  it  is  intended  that  most  tools  in  use  in  the 
Ada  support  environment  be  written  in  Ada,  they  will  be 
fully  transportable.  This  will  further  reduce  the 
retraining  problem. 

Another  benefit  of  standardization  is  the  incentive 
it  gives  programmers  to  write  useful  programs  and 
packages,  since  the  potential  market  is  much  larger  than 
for  a  similar  program  written  for  one  machine  or  family  of 
machines.  Hopefully  this  will  lead  to  the  emergence  of 
large  software  houses  and  catalogs  from  which  a  programmer 
can  order  the  packages  and  subprograms  needed  to  do  a 
project.  The  packages  and  subprograms  can  then  be 
compiled  with  new  code  to  produce  a  new  pr  cram  much  more 
quickly. 


2.4  SCOPE  OF  THE  THESIS 

This  section  outlines  the  scope  of  the  thesis  effort. 
The  scope  can  be  broken  into  three  parts,  the  features  of 
Ada  that  were  implemented,  the  features  of  Ada  that 
designs  were  done  for,  and  the  features  of  Ada  that  were 
ignored  for  this  thesis  effort.  Since  Ada  is  such  a  large 
language  and  time  was  limited  a  workable  subset  of  the  it 
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had  to  be  chosen  and  some  of  the  features  had  to  be  left 


2.4.1  FEATURES  IMPLEMENTED 


The  features  of  Ada  implemented  in  the  Adal  compiler 
included  the  AdaO  subset,  new  data  types,  functions,  the 
remaining  operators,  and  some  of  the  remaining  statement 
forms.  These  features  are  explained  in  more  detail  below. 


2. 4. 1.1  FEATURES  OF  THE  ADAO  SUBSET 


The  first  things  to  be  included  in  the  Adal  subset 
were  any  features  already  implemented  through  the  AdaO 
subset.  Since  this  thesis  effort  is  based  on  the  AdaO 
compiler,  developed  by  Scott  Ferguson,  all  features  of  it 
were  included.  The  code  from  the  AdaO  compiler  required 
some  modification  to  work  for  the  expanded  Adal  subset. 


2. 4. 1.2  DATA  TYPES 


The  next  feature  added  to  the  Adal  subset  was  two  new 
data  types,  booleans  and  characters.  These  were  added 
since  the  AdaO  subset  was  integer  only.  Unfortunately, 
the  addition  of  new  data  types  required  most  of  the  code 
written  for  the  AdaO  compiler  to  be  modified.  The 
modifications  to  the  code  were  made  to  allow  the  compiler 


to  do  type  checking  and  report  typing  errors. 
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2. 4. 1.3  FUNCTIONS  AND  PROCEDURES 

The  next  feature  added  to  the  Adal  subset  was 
functions.  The  AdaO  subset  allowed  only  procedures. 
Since  a  function  is  essentially  a  procedure  that  returns  a 
value  functions  were  easy  to  include. 


2. 4. 1.4  NEW  OPERATORS 

The  AdaO  subset  left  out  some  of  the  operators 
defined  in  the  Ada  grammar.  These  operators  are  included 
in  the  Adal  subset.  The  new  operators  are  the  boolean 
operators,  and  then,  or  else,  and  xor,  and  the  integer 
operators  rem,  mod,  abs,  and  the  exponentiation  operator, 
** 


2. 4. 1.5  ADA  STATEMENT  FORMS 

Most  of  the  Ada  statement  and  expression  forms  are 
included.  The  statement  forms  included  are  the 
assignment,  if-then-elsif-else ,  iterative  loops,  while 
loops,  return,  and  null  statements.  The  statement  forms 
missing  from  the  compiler  are  mostly  associated  with 
tasking.  Since  tasking  was  not  implemented  these  could  not 
be  included. 


15 


ADA 


2. 4. 1.6  COMMENTS 

Comments  were  the  final  feature  added  to  the  Adal 
grammar.  The  comments  are  a  limited  subset  of  the  Ada 
comment  feature.  The  limitation  was  added  to  make 
comments  easier  to  handle  for  the  compiler.  Ada  allows 
comments  to  occur  at  any  point  in  a  program.  The  Adal 
subset  limits  comments  to  be  used  as  a  program  header,  as 
a  regular  statement,  and  to  follow  statements  and  variable 
declarations.  These  places  were  thought  to  be  the  most 
useful  and  also  are  the  places  within  a  program  that  a 
user  usually  puts  comments. 

2.4.2  FEATURES  DESIGNED 

Designs  were  done  to  allow  several  of  the  more 
interesting  features  of  Ada  to  be  implemented  at  a  later 
time.  These  features  are  overloading  of  names  and 
operators,  packages,  user  defined  data  types,  and  passing 
parameters  to  subprograms. 

2. 4. 2.1  OVERLOADING  OF  NAMES  AND  OPERATORS 

The  first  design  done  was  an  algorithm  to  handle 
overloading  of  names  and  operators.  Several  good 
algorithms  exist  (Ref  2,14,16)  to  handle  the  problems  of 
operator  and  name  identification.  All  that  should  be 
needed  is  a  "black  box"  implementation  of  one  of  them  to 
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do  a  prewalk  of  the  abstract  syntax  tree  and  hang  the 
correct  types  onto  the  various  structures. 

The  code  involved  in  such  a  tool  is  long  and  very 
involved,  even  though  several  of  the  references  actually 
give  most  of  the  code  or  pseudo-code  for  their  algorithm. 
The  time  needed  to  include  this  tool  is  beyond  the  scope 
of  this  thesis  effort. 

Also  overloading  is  not  really  essential  to  getting  a 
subset  in  which  these  tools  could  be  rewritten.  The  only 
change  to  the  compiler  that  would  be  needed  to  include 
this  semantic  analysis  tool  is  the  call  to  it  when  an 
expression  is  encountered  and  the  deletion  of  calls  to  the 
symbol  table  routines  when  a  name  is  finally  found  since 
the  type  and  symbol  table  information  will  already  be 
attached  to  the  node.  A  design  of  the  proposed  semantic 
analyzer  is  presented  in  chapter  5  and  Appendix  D. 

2. 4. 2. 2  PACKAGES 

The  second  feature  designed  were  data  structures  to 
allow  implementation  packages.  The  design  is  presented  in 
chapter  5.  The  current  implementation  in  no  way  precludes 
or  limits  the  inclusion  of  the  design. 
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2. 4. 2. 3  DATA  TYPES 

The  data  structures  needed  to  allow  user  defined  data 
types  were  designed  next.  These  were  only  designed 
because  the  code  needed  to  do  semantic  verification  was 
not  written.  Even  without  overloading  the  code  to  do  type 
verification  of  expressions  was  difficult  to  implement 
correctly.  Since  a  semantic  analyzer  will  eliminate  the 
need  for  this  code,  I  felt  writing  extra  code  that  would 
later  need  to  be  eliminated  was  wasteful  of  time  and 
effort.  The  data  structures  needed  to  implement  user 
defined  data  types  were  designed  and  are  presented  in 
chapter  5. 


2. 4. 2. 4  PASSING  PARAMETERS  TO  SUBPROGRAMS 

The  final  design  done  was  of  an  algorithm  to  allow 
parameters  to  be  passed  to  subprograms.  The  algorithm 
designed  is  presented  in  chapter  5  and  Appendix  C. 

2.4.3  FEATURES  NOT  INCLUDED  IN  THE  SUBSET 

Since  time  was  limited  certain  features  had  to  be 
excluded  from  the  subset.  Several  papers  (Ref  5,15,17  ) 
influenced  my  decisions  regarding  what  features  to 
exclude.  These  papers  pointed  out  problems  with  the  Ada 
grammar,  problems  with  a  feature  or  the  fact  that  a 
feature  was  extraneous  to  the  language.  One  of  these 


18 


ADA 


papers  quoted  Niklaus  Wirth  who  said 


The  choice  of  what  is  to  be  omitted  from  a  new 
language  is  in  practice  much  more  critical  than 
the  choice  of  what  is  to  be  included.  The 
decision  to  omit  a  feature  requires  not  only 
familiarity  with  this  feature  (and  knowledge  of 
how  to  live  without  it)  but  the  courage  to  face 
the  inevitable  criticism  of  its  absence  in  the 
new  language  in  spite  of  its  presence  in  another 
existing  language  (Ref  15) . 


Interestingly  this  quote  was  taken  from  the  Green 
Reference  Manual  which  was  the  original  Ada  design  but  it 
was  omitted  from  later  versions  of  the  manual.  Wirth  was 
referring  to  the  fact  that  DOD  was  attempting  to  include 
too  many  features  into  Ada  to  be  popular.  He  was  afraid 
Ada  would  follow  the  same  path  as  PL/1  which  has 
essentially  died  in  spite  of  the  backing  given  it  by  IBM 
(Ref  17) .  Most  of  the  features  excluded  from  this  subset 
are  features  that  the  user  can  do  without  and  in  fact  many 
of  them  can  be  simulated  using  the  features  contained  by 
the  language  subset  that  was  implemented. 


2. 4. 3.1  TASKING 


The  first  feature  excluded  from  the  subset  was 
tasking.  Many  problems  with  this  feature  are  pointed  out 
in  a  technical  note  from  the  Defense  Communications 
Engineering  Center  (Ref  5) .  Since  these  problems 


complicate  the  understanding  of  exactly  how  tasking  is 
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supposed  to  work  and  therefore  how  it  must  be  implemented, 
tasking  was  excluded. 

Another  factor  which  helped  allow  the  exclusion  of 
tasking  is  that  a  tasking  Ada  subset  compiler  already 
existed  at  AFIT  (Ref  11)  and  it  could  be  used  or  rewritten 
for  later  integration  into  the  syntax  directed  editor 
environment.  This  rewrite  would  probably  have  taken  most 
of  the  time  allotted  to  the  development  of  this  subset 
compiler  and  thus  the  other  features  would  not  have  been 
implemented . 


2. 4. 3. 2  GENERIC  PACKAGES 

The  next  feature  to  be  eliminated  was  generic 
packages.  The  main  reason  for  not  implementing  generic 
packages  was  that  packages  themselves  were  not  implemented 
and  generic  packages  cannot  be  implemented  until  such 
time . 


2. 4. 3. 3  SEPARATE  COMPILATION 

The  next  feature  eliminated  was  the  separate 
compilation  of  Ada  sub-units.  This  feature  only 
complicates  the  design  of  the  how  the  generated  code  is 
stored  and  written  out.  The  current  design  does  not 
preclude  the  insertion  of  code  from  a  later  compile  but  it 
is  not  easily  extended  to  allow  such  an  insertion. 
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One  method  that  will  work  is  to  generate  a  jump 
statement  as  the  specification  is  compiled.  When  the 
sub-unit  body  is  compiled  fix  that  statement  to  jump  to 
where  the  actual  code  is  placed.  This  would  allow  the 
code  to  be  placed  anywhere  in  the  code  array  that  space 
permits . 

One  problem  comes  up  when  this  type  of  separate 
compilation  is  done.  This  is  the  problem  of  what  the 
symbol  table  looks  like  when  the  procedure  should  have 
been  encountered.  The  solution  to  this  problem  is  not 
trivial  since  the  entire  symbol  table  up  to  the  point 
where  the  specification  is  found  must  be  saved  for  use 
when  the  subunit  is  compiled.  Due  to  the  limitation  of 
time  and  the  fact  that  this  feature  is  not  needed  to 
attain  the  goal  of  writing  the  tools  into  Ada  it  was  not 
included. 


2. 4. 3. 4  THE  GOTO  STATEMENT  ' 


The  next  feature  eliminated  was  the  goto  statement. 
This  feature  is  not  needed  due  to  the  numerous  control 
structures  already  available  in  Ada.  Since  Ada  is  such  an 
otherwise  structured  language  the  rationale  for  including 
a  goto  statement  is  hard  to  figure  out.  Its  inclusion,  no 
matter  how  structured,  can  only  lead  to  misuse  or  very 
complicated  compiler  restraints  to  ensure  proper  usage. 


Since  the  arguments  against  the  inclusion  of  the  goto 
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outweigh  any  possible  gain  from  its  inclusion,  the  goto 
was  not  included  in  the  subset. 


2. 4. 3. 5  OTHER  FEATURES  LEFT  OUT 

Several  other  features  were  not  implemented.  Most  of 
these  were  excluded  for  reasons  of  time  or  not  being 
needed  for  the  chosen  goal.  Although  these  features  are 
of  interest  they  tend  to  add  little  to  the  capabilities  of 
the  subset.  These  include  private  types,  access  types, 
named  parameters,  and  input/output  of  enumeration  types. 

The  design  of  the  compiler  in  no  way  precludes  the 
later  inclusion  of  any  of  these  features  and  in  fact  many 
of  the  data  structures  used  by  the  compiler  were  designed 
with  the  excluded  factors  being  considered.  The  goal 
behind  the  design  was  to  allow  an  easier  extension  than 
the  AdaO  subset  compiler  did.  Several  fields  of  the  data 
structures  are  not  even  used  but  were  included  to  handle 
the  analysis  of  these  features. 


2.5  PROBLEMS  WITH  THE  ADA  GRAMMAR 

The  development  of  this  subset  and  the  compiler  for 
it  also  brought  out  several  problems  with  the  Ada  grammar 
as  presented  in  the  Ada  reference  manual  (Ref  7) .  These 
problems  were  mostly  in  areas  where  the  Ada  syntax 
specification  allows  the  use  of  a  non-terminal  with  a 
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pre-fixed  italicized  modifier.  The  italicized  modifier 
creates  a  variety  of  the  non-terminal,  but  syntactically 
the  modifier  is  ignored  (Ref  7,17).  For  example 
procedure_name  and  package_name  are  varieties  of  name. 

Usually  these  qualified  non-terminals  are  used  in 
such  restricted  situations  that  the  italicized  modifier 
can  be  retained  without  causing  the  grammar  to  become 
ambiguous.  Since  the  non-terminal  can  be  restricted  in 
this  way,  the  Adal  subset  incorporated  these  restrictions. 

Incorporating  these  restrictions  into  the  Adal  subset 
accomplished  two  things.  First,  it  simplified  the  user's 
job  when  writing  a  program  with  the  syntax  directed  editor 
This  is  because  some  choices  that  would  otherwise  be 
available  to  the  user  are  eliminated.  This  also 
eliminates  the  need  for  the  compiler  to  do  some  of  the 
semantic  checks  that  would  be  necessary  if  the 
restrictions  were  not  incorporated.  This  is  because  the 
restrictions  eliminate  choices  that  would  be  syntactically 
correct  but  semantically  incorrect. 

For  example,  in  the  full  Ada  grammar  procedure_name 
is  interpreted  simply  as  name.  The  legal  choices  for  name 
are  shown  in  figure  2-2.  Of  these  choices  only  identifier 
is  semantically  correct.  Thus  in  the  Adal  grammar 
procedure_name  was  replaced  with  identifier  (see  Appendix 
A).  This  greatly  simplifies  not  only  the  user's  job  when 
entering  programs  but  also  the  compiler  since  the  illegal 
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choices  need  not  be  considered. 


name  : : =  identifier 

indexed_component 

selected_component 

function_call 

slice 

attribute 

operator_symbol 


Figure  2-2  Ada  Name  Production 


Most  of  the  other  problems  with  the  grammar  are 
resolved  by  the  user  as  he  walks  through  the  parse  and 
chooses  the  type  of  production  or  construct  he  wants  to 
use  next.  This  means  the  compiler  always  knows  what  it  is 
working  on  and  does  not  need  to  do  any  backtracking. 


2.6  SIMPLIFICATIONS  TO  THE  ADA1  GRAMMAR 

After  the  Adal  grammar  was  developed,  it  was  input  to 
the  META  program  (Ref  9) .  The  META  program  is  used  to 
convert  a  grammar  from  its  external,  English  form  to  an 
internal  representation  that  the  syntax  directed  editor 
and  the  other  tools  can  use. 

META  does  some  checking  of  the  input  grammar.  It 
ensures  that  the  grammar  is  complete  in  the  sense  that  no 
undefined  non-terminals  exist.  It  also  checks  to  see  if 
the  grammar  could  be  simplified  by  either  eliminating 
unused  productions  or  by  combining  two  or  more  productions 
into  a  single  production. 
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Unused  productions  are  automatically  eliminated. 
Unfortunately  they  are  not  tagged  as  such  in  anyway.  Only 
a  thorough  analysis  of  the  output  from  META  would  reveal 
those  productions  which  were  eliminated.  A  production  is 
unused  if  its  non-terminal  is  not  used  on  the  right-hand 
side  of  any  other  production.  There  is  one  exception  to 
this  rule.  That  is  the  first  production  in  the  grammar. 
This  production  is  considered  to  be  the  goal  or  start 
symbol  for  the  grammar  and  as  such  does  not  have  to  appear 
on  the  right  side  of  a  production. 

META  also  points  out  several  potential 
simplifications  to  the  input  grammar.  These  are  pointed 
out  as  a  single  unconditional  term,  a  single  alternative, 
and  an  alternation  alternative.  Each  of  these  potential 
simplifications  is  the  result  of  the  subset  nature  of  the 
Adal  grammar,  and  the  causes  are  explained  below. 


2.6.1  A  SINGLE  UNCONDITIONAL  TERM 

The  first  potential  simplification  that  META  points 
out  is  a  single  unconditional  term.  This  is  a 
non-terminal  that  is  replaced  by  a  single  terminal  or 
non-terminal.  For  example  A  ::=  B?.  META  is  suggesting 
the  grammar  could  be  simplified  by  eliminating  the 
production  and  replacing  all  occurences  of  the 
non-terminal  A  with  B. 

Several  productions  of  this  form  appear  in  the  Adal 
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grammar.  These  productions  are  due  to  the  way  the  Adal 
subset  was  developed.  These  productions  are  actually 
concatenations  or  alternations  in  the  full  Ada  grammar.  A 
decision  was  made  to  leave  the  subset  as  is  since  this 
makes  future  expansion  of  the  subset  and  the  compiler 
easier  and  it  does  not  make  the  syntax  directed  editor  any 
more  difficult  to  use. 

An  example  of  a  production  of  this  type  in  the  Adal 
grammar  is  the  production  for  decimal_number  shown  in 
figure  2-3. 

Adal 

decimal_number  =  integer  ; 

Full  Ada 

decimal_number  =  integer  [decimal_part] 

[exponent]  ; 

Figure  2-3  Decimal  number 

2.6.2  A  SINGLE  ALTERNATIVE 

The  second  potential  simplification  pointed  out  by 
META  is  a  single  alternative.  This  is  similar  to  the 

single  unconditional  term  except  that  the  production 
involved  is  an  alternation  rather  than  a  concatenation. 
For  example  B  =  <  C  >  ;.  By  pointing  this  out  META  is 

suggesting  the  grammar  could  be  made  simpler  by  making 


26 


ADA 


this  production  into  a  concatenation  as  B  =  C  ;  or  by 
replacing  all  occurences  of  B  with  C  and  eliminating  this 
production . 

Several  productions  of  this  form  appear  in  the  Adal 
subset.  These  productions  are  again  a  result  of  the  way 
the  Adal  subset  was  developed.  These  productions  are 
actually  multi-alternatives  in  the  full  Ada  grammar. 
Since  simplifying  the  grammar  does  not  make  the  user's  job 
any  easier,  the  grammar  was  left  unsimplified.  This  also 
makes  expansion  of  the  subset  grammar  and  the  compiler 
easier . 


An  example 

production 

of 

this  type  in 

the  Adal 

grammar  is  the 

production 

for 

a  designator. 

shown  in 

figure  2-4. 

Adal 

designator  =  <  identifier  >  ; 

Full  Ada 

designator  =  <  identifier 

op_symbol  >  ; 

Figure  2-4  Designator  Productions 
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2.6.3  AN  ALTERNATION  ALTERNATIVE 

The  third  potential  simplification  that  META  points 
out  is  an  alternation  alternative.  This  results  when  a 
choice  of  an  alternation  is  an  alternation  in  its  own 
right.  An  example  is  shown  in  figure  2-5a.  META  is 
suggesting  that  these  two  productions  can  be  combined  and 
the  grammar  simplified  as  shown  in  figure  2-5b.  If  the 
non-terminal  C  only  appears  in  other  alternations  it  can 
be  eliminated  from  the  grammar  since  after  the 
combinations  are  done  it  will  not  appear  on  the  right  hand 
side  of  any  production. 

(a) 

A  =  B 

I  C  ; 

C  =  D 

!  E  ? 

(b) 

A  =  B 
D 

E  ? 

C  =  D 

I  E  ; 

Figure  2-5  Simplification  of  an  Alternation  Alternative 

Several  productions  of  this  form  appear  in  the  Adal 
grammar.  These  do  not  result  from  the  way  the  Adal  subset 
was  developed  but  are  actually  caused  by  the  Ada  grammar 
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itself  and  the  way  the  productions  must  be  formed  for 
input  to  META.  In  this  case  simplifying  the  grammar 
probably  would  not  make  expansion  of  the  subset  grammar  or 
the  compiler  any  more  difficult,  but  in  most  cases  the 
simplification  does  not  result  in  any  true  simplification 
since  no  productions  are  eliminated.  Doing  the 
simplifications  can  make  the  user's  job  somewhat  more 
difficult  since  he  must  choose  from  a  larger  list  of 
alternatives  when  a  choice  must  be  made. 

The  Adal  grammar  was  left  unsimplified  to  avoid 
potentially  overloading  the  user  with  too  many  choices  at 
any  one  time.  Another  factor  that  influenced  this 
decision  is  that  in  some  cases  the  extra  information 
gained  through  the  extra  decision  was  very  useful  in  the 
semantic  analysis  and  code  generation  for  a  program. 

An  example  of  this  type  of  production  in  the  Adal 
grammar  is  the  productions  for  primary  and  boolean_value 
and  is  shown  in  figure  2-6. 

primary  =  <  decimal_number 
name 

nested_exp 
char_lit 
boolean_value 
func_call  >  ? 

boolean_value  =  <  "true" 

"false"  > 

Figure  2-6  Primary  and  Boolean  Value  Productions 
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3.  TOOLS  IN  THE  SUPPORT  ENVIRONMENT 

The  tools  of  the  support  environment  work  together  to 
accomplish  a  common  goal.  This  goal  is  to  simplify  the 
program  development  process  for  the  programmer.  To  do 
this  efficiently  the  tools  must  communicate  with  each 
other.  Since  the  tools  work  independently,  the 
communication  is  done  through  a  common  data  structure  that 
is  retained  throughout  the  development  cycle.  This  data 
structure  is  the  abstract  syntax  tree  representation  of 
the  program  that  the  syntax  directed  editor  creates  as  the 
program  is  entered. 

This  abstract  representation  of  the  program  is  used 
or  manipulated  by  each  of  the  tools  in  the  support 
environment.  The  tools  currently  implemented  are  a  syntax 
directed  editor,  a  compiler,  an  interpreter/debugger  and  a 
program  lister.  Many  other  tools  can  be  written  to  use 
the  abstract  representation  of  the  program.  These  tools 
include  code  optimizers,  cross  reference  routines, 
semantic  analyzers,  and  execution  analyzers.  The  nature 
of  these  tools  is  limited  only  by  the  imagination  and 
skill  of  a  user  or  group  of  users. 

3.1  SYNTAX  DIRECTED  EDITOR 

The  syntax  directed  editor  is  the  first  tool 
encountered  by  a  programmer.  The  syntax  directed  editor 
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is  used  to  enter  a  program  into  the  environment.  In  this 
sense  a  syntax  directed  editor  is  a  text  editor.  It 
differs  from  a  standard  text  editor  in  its  use  and 
ultimate  goal.  A  standard  text  editor  allows  the  user  to 
enter  any  text  desired.  The  output  of  a  standard  text 
editor  is  the  text  that  was  entered.  A  syntax  directed 
editor  allows  the  user  to  enter  text  that  is  limited  by 
the  syntax  or  grammar  of  the  language  the  program  is 
written  in.  The  output  of  the  syntax  directed  editor  is  a 
syntactically  correct  program  that  the  other  tools  can 
work  with. 

The  syntax  directed  editor  is  not  part  of  this  thesis 
effort.  It  is  an  integral  part  of  the  programming 
environment  and  is  used  to  create  the  abstract  syntax  tree 
the  other  tools  of  the  environment  use.  Its  use  is 
necessary  to  be  able  to  use  the  compiler  and  interpreter 
being  implemented  for  this  thesis  effort.  The  syntax 
directed  editor  was  originally  developed  by  Scott  E. 
Ferguson  (Ref  9)  and  was  moved  to  the  VAX  11/780  bv  John 
Kos low. 


3.1.1  USING  THE  SYNTAX  DIRECTED  EDITOR 

To  use  the  syntax  directed  editor  the  programmer  must 
tell  it  the  name  for  the  new  program  and  what  language  the 
program  is  to  be  written  in.  The  syntax  directed  editor 
then  creates  a  template  of  the  syntactically  legal 
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constructs  for  a  program  in  that  language.  The  user  must 
then  "walk"  around  that  template  and  choose  the  elements 
to  be  included  in  the  program.  With  each  choice  the 
syntax  directed  editor  replaces  the  object  chosen  with  its 
own  template.  This  process  of  replacement  continues  until 
the  user  is  left  with  no  more  choices  and  the  program  is 
fully  written. 

For  example  in  the  Adal  language  a  program  is  a 
compilation_unit .  Since  a  compi lation_unit  is  an 
alternation  the  user  must  choose  whether  to  write  a 
function  or  a  procedure.  After  the  choice  is  made  the 
syntax  directed  editor  displays  the  template  that  was 
chosen.  It  is  this  template  that  the  user  sees  when  he 
starts  to  enter  a  program.  Suppose  a  procedure_body  was 
chosen,  the  user  descends  the  tree  into  the  procedure_body 
and  must  satisfy  the  requirements  of  a 
procedure_specif ication.  This  is  simply  an  identifier 
which  is  entered  simply  by  typing  in  the  name. 

This  "walk"/selection  process  continues  until  the 
program  has  been  fully  entered.  The  programmer  can  then 
exit  the  syntax  directed  editor  or  call  the  compiler, 
interpreter,  or  program  lister.  The  abstract  syntax  tree 
representation  of  the  program  is  stored  by  the  syntax 
directed  editor  before  an  exit  is  allowed.  A  more 
complete  explanation  of  the  syntax  directed  editor  can  be 
found  in  the  thesis  written  by  Scott  Ferguson  (Ref  9). 
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The  use  of  a  syntax  directed  editor  can  have  several 
advantages  and  disadvantages.  These  are  outlined  below. 

3.1.2  ADVANTAGES  OF  A  SYNTAX  DIRECTED  EDITOR 

The  use'  of  a  syntax  directed  editor  leads  to  several 
advantages  that  can  help  later  in  the  program  development 
cycle.  The  first  and  most  important  advantage  is  the 
compiler  does  not  have  to  do  any  syntactic  analysis.  This 
can  dramatically  speed  up  the  compilation  process  since 
the  compiler  does  not  have  to  recreate  the  syntax  tree 
whenever  the  program  is  recompiled.  It  also  allows  the 
compiler  to  concentrate  on  other  aspects  of  the 
compilation  process.  These  aspects  include  semantic 
checking,  error  recovery,  and  code  optimization.  The 
compiler  essentially  becomes  a  semantic  analyzer  and  a 
code  generator. 

A  second  advantage  of  the  syntax  directed  editor  is 
the  fact  that  it  is  independent  of  the  language  the 
programmer  is  using.  This  means  it  does  not  have  to  be 
rewritten  for  each  new  language  a  programmer  wants  to  use. 
Only  the  language's  syntax  need  be  created  and  input  to 
the  META  preprocessor  described  earlier.  This  also  means 
a  programmer  does  not  have  to  remember  how  many  different 
editors  work  since  the  same  editor  will  be  used  for  each 
project.  This  has  one  other  advantage  since  only  one 
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editor  is  needed  less  secondary  storage  is  needed  to  keep 
editors  online. 

A  third  advantage  of  a  syntax  directed  editor  is  in 
the  more  efficient  use  of  the  computer.  Several  aspects 
of  this  have  already  been  pointed  out.  The  first  is  the 
compiler  does  not  have  to  reanalyze  the  program  each  time 
it  is  recompiled.  Another  is  that  the  programmer  does  not 
have  to  wait  for  a  printout  to  be  able  to  go  in  and  fix  an 
error.  This  can  save  not  only  time  but  other  resources 
such  as  paper  or  wear  and  tear  on  a  printer. 

Another  more  efficient  use  of  the  computer  is 
achieved  by  a  syntax  directed  editor  since  the  CPU  has 
functions  other  than  waiting  for  a  user  to  make  inputs  to 
perform.  Since  most  CPU's  can  handle  data  much  faster 
than  a  user  can  enter  it,  the  CPU  tends  to  sit  idle  when 
it  could  be  doing  other  tasks.  One  of  these  tasks  is  the 
creation  of  the  various  syntax  nodes  being  put  to  use  by 
the  programmer . 

Another  task  the  CPU  could  be  doing  is  background 
compilation.  The  compiler  or  some  portion  of  it  could  be 
running  as  a  background  task  to  the  syntax  directed 
editor.  A  major  problem  must  be  overcome  before  this  is 
attempted.  That  problem  is  how  _..e  editor  and  the 
compiler  communicate  with  each  other  to  avoid  the  editor 
changing  the  program  that  the  compiler  has  already 
generated  code  for.  Also  the  editor  must  ensure  it  does 
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not  destroy  a  subtree  the  compiler  is  working  while  the 
compiler  is  analyzing  it.  For  these  reasons  and  a  lack  of 
time  this  feature  was  not  implemented. 


3.1.3  DISADVANTAGES  OF  A  SYNTAX  DIRECTED  EDITOR 

A  syntax  directed  editor  can  have  disadvantages.  The 
first  of  these  is  the  user  must  have  much  more  knowledge 
of  the  grammar  and  syntactic  structure  of  the  language  the 
program  is  written  in.  This  is  due  to  the  way  the  user 
must  interact  with  the  syntax  directed  editor  to  indicate 
what  template  to  use  next.  This  aspect  will  be  further 
discussed  in  the  next  chapter.  This  interaction  may  also 
force  a  user  to  receive  extra  training  and  it  may  take 
some  users  longer  to  learn  how  to  properly  use  the  new 
tool . 

The  other  main  disadvantage  to  a  syntax  directed 
editor  is  the  syntax  tree  can  take  up  to  eight  times  more 
secondary  storage  than  its  text  based  counter  part.  This 
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3.2  COMPILER 

The  compiler  in  this  environment  becomes  a  simple 
tree  walking  routine.  It  systematically  walks  around  the 
tree  hanging  code  fragments  for  the  node  it  is  currently 
on.  The  code  fragments  are  generally  hung  only  on  the 
leaf  nodes  of  the  tree. 

A  function  is  developed  for  each  type  of  node  that 
the  tree  might  contain.  This  makes  the  compiler  somewhat 
easier  to  modify  or  expand  since  only  the  functions  for 
the  productions  that  changed  must  be  modified.  An 
exception  to  this  occurs  when  a  change  like  adding  data 
types  to  the  language  is  made.  All  functions  must  be 
examined  to  see  if  type  checking  is  needed.  One  way 
around  this  is  to  write  a  separate  semantic  analyzer  that 
pre-walks  the  tree  hanging  type  and  symbol  table 
information  onto  the  nodes.  The  current  implementation  of 
the  compiler  is  explained  in  more  detail  in  the  next 
chapter . 

3.2.1  INCREMENTAL  COMPILATION 

The  compiler  can  also  use  this  structure  to  save 
information  that  can  be  used  when  a  program  is  recompiled. 
If  the  nodes  are  marked  to  indicate  a  change  was  made  that 
affected  that  node  then  the  compiler  can  reuse  any 
information  that  is  associated  with  unchanged  nodes. 
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Since  ADA  is  such  a  structured,  type  oriented  language 
this  feature  was  not  implemented.  This  was  to  ensure  the 
semantic  correctness  of  the  program  being  compiled,  since 
changes  in  declarations  and  external  packages  can  have 
unknown  affects.  Such  changes  can  even  affect  areas  of  a 
program  that  have  not  been  changed  for  a  long  time. 

3.2.2  ERROR  DETECTION  AND  RECOVERY 

Using  the  abstract  syntax  representation  of  the 
program  and  knowing  that  the  program  is  syntactical ly 
correct  makes  error  detection  and  recovery  done  by  the 
compiler  much  easier.  Since  the  compiler  knows  at  all 
times  what  construct  it  is  working  on,  no  error  recovery 
in  the  usual  sense  is  needed.  All  the  compiler  needs  to 
do  is  ascend  the  tree  to  a  node  above  the  error  and 
continue  as  if  the  subtree  with  the  error  is  ok.  This 
allows  the  compiler  to  do  more  extensive  error  checking 
during  the  initial  compile  and  also  helps  eliminate  the 
usual  stream  of  false  errors  that  are  caused  while  the 
compiler  tries  to  resynchronize  itself. 

The  only  limitation  on  this  error  detection  is  the 
maximum  number  of  errors  a  user  wants  to  allow  before  the 
compiler  quits.  Since  error  flags  are  stored  in  the 
syntax  tree  itself  or  in  a  similar  structure,  the  limiting 
factor  is  how  much  storage  is  available  for  these  errors. 
These  error  flags  have  pointers  into  the  syntax  tree  at 
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the  node  with  the  error.  The  syntax  directed  editor  can 
then  be  invoked  and  will  point  to  the  first  erroneous 
node.  The  editor  can  also  have  the  error  message 
available  which  relieves  the  programmer  from  having  to 
wait  for  a  printout.  This  will  save  the  programmer  time 
and  allow  programs  to  be  written  and  debugged  faster. 


3.3  INTERPRETER 

The  interpreter  or  run  time  mechanism  can  use  the 
information  stored  in  the  syntax  tree  to  allow  the  input 
and  output  of  enumeration  types,  to  do  range  checking,  and 
any  other  run  time  checks  that  might  be  desired.  In  many 
cases  these  checks  can  be  done  dynamically  by  the 
interpreter  without  the  need  for  extra  code  being 
generated  by  the  compiler.  This  can  save  time  in  the 
compile  process  and  also  means  that  it  will  be  easier  to 
override  these  run  time  checks  since  they  only  need  be 
turned  off  in  the  interpreter  and  no  recompilation  is 
needed . 

3.4  A  DEBUGGING  TOOL 

An  interactive  debugging  tool  can  be  used  to  trace 
the  execution  of  a  computer  program.  Debugging  tools 
exist  but  they  are  usually  limited  in  their  capabilities. 
Using  information  contained  in  the  syntax  tree,  the 
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debugger  can  show  the  programmer  exactly  what  is  happening 
during  execution.  This  can  help  pinpoint  an  error  and 
show  the  programmer  exactly  where  it  is.  This  is 

especially  helpful  if  the  error  is  in  the  middle  of  a 
complex  statement  or  if  the  error  does  not  cause  the 
program  to  terminate.  The  current  implementation  combines 
the  interpreter  and  debugging  tools  into  a  single  tool. 
This  is  not  the  only  way  it  could  be  done,  but  due  to  the 
simple  nature  of  the  debugging  tool  it  was  the  easiest  way 
to  get  them  working. 


3.5  PROGRAM  LISTER 

A  program  lister  uses  the  information  stored  in  the 
syntax  tree  and  the  syntax  description  file  to  produce 
nicely  formatted  listings.  Using  other  information  in  the 
syntax  tree  a  lister  could  be  written  to  generate  cross 
reference  listing  and  other  useful  outputs.  If  done 
properly  these  listings  are  more  detailed  than  the  usual 
listings  produced  by  a  compiler. 

An  added  feature  of  this  lister  is  that  it  is  usually 
independent  of  the  programming  language  in  use.  This  is 
also  true  of  the  syntax  directed  editor  and  means  that 
only  the  compiler  and  grammar  need  to  be  rewritten  for  the 
syntax  directed  editor  to  work  on  another  programming 
language. 
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Like  the  syntax  directed  editor,  the  lister  was  not 
directly  part  of  this  thesis  effort.  It  is  part  of  the 
effort  done  by  Scott  Ferguson  and  moved  to  the  VAX  11/780 
by  John  Koslow.  It  was  used  during  this  thesis  effort  to 
produce  listings  of  the  programs  used  to  test  the 
compiler . 


3.6  CODE  LISTER 

The  code  lister  is  a  simple  tool  to  extract  the  code 
generated  by  the  compiler  and  transform  it  into  a  readable 
format.  The  code  lister  is  newly  implemented  as  part  of 
this  thesis  effort.  It  is  dependent  only  on  the  set  of 
"executable"  instructions  being  used  by  the  compiler  and 
interpreter.  It  is  the  only  tool  of  the  support 
environment  that  does  not  use  the  abstract  syntax 
representation  of  the  program. 
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4.0  THE  ADA1  COMPILER 

The  Ada!  compiler  can  be  split  into  three  interacting 
but  separate  parts.  These  are  the  semantic  analyzer,  the 


symbol 

table  routines, 

and 

the 

code 

generator.  The 

semantic 

analyzer  is 

used 

to 

hang 

the  types  onto 

expressions  and  variables.  The  symbol  table  routines  are 
used  to  insert  and  look  up  names  in  the  symbol  table.  The 
code  generator  is  used  to  produce  code  for  the  program. 

These  three  parts  work  together  to  compile  an  Adal 
program.  The  code  generator  is  the  controlling  program 
and  it  calls  the  other  two  as  needed.  The  semantic 
analyzer  is  used  to  preview  an  Adal  expression  and 
determine  its  type.  This  preview  makes  the  generation  of 
code  much  easier.  The  symbol  table  routines  are  called  by 
both  the  code  generator  and  the  semantic  analyzer  as 
necessary. 

This  chapter  will  discuss  the  implementation  of  the 
code  generator  and  the  symbol  table  routines.  A  proposed 
design  for  the  semantic  analyzer  will  be  presented  in  the 
next  chapter. 

Since  no  means  currently  exists  for  specifying 
semantic  actions  in  the  META  syntax  description,  the  code 
generator  must  be  coded  separately.  Fortunately  the  code 
generator  merely  needs  to  walk  the  tree  building  the 
symbol  table  and  generating  code  for  the  pseudo-machine. 
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4.1  PROGRAM  TREE  WALK 

The  need  for  a  parsing  step  is  eliminated  since  the 
structure  and  syntactic  correctness  of  the  program  tree  is 
assured.  Walking  the  tree  provides  access  to  the 
syntactic  elements  of  the  program.  Since  the  code  to  walk 
the  tree  models  the  syntactic  structure  of  the  language, 
each  non-terminal  in  the  grammar  maps  into  a  function  to 
evaluate  and  validate  its  subtree.  The  function  is  passed 
a  single  argument  which  is  the  root  node  of  the  subtree. 
Thus  to  start  the  compilation  process  the  root  node  of  the 
tree  is  passed  to  the  function  goal. 

Since  a  non-terminal  can  be  either  a  concatenation  or 
an  alternation,  two  basic  function  structures  are  used. 

4.1.1  CONCATENATION  NODES 

For  a  concatenation  non-terminal,  the  function 
consists  of  a  series  statements  to  analyze  and  validate 
each  child  node  in  turn.  Non-terminals  are  processed  by 
calling  subroutines  to  analyze  and  validate  their 
subtrees.  Terminal  strings  and  sets  are  processed  for 
their  value.  Terminal  strings  present  in  the  grammar  are 
not  present  in  the  abstract  syntax  tree  so  they  present  no 
real  problem.  For  example  the  syntax  for  a  function  body 
is  given  in  figure  4-1.  Sample  code  to  accept  this  syntax 
is  shown  in  figure  4-2. 
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func_body  = 

func_spec  "is" 

(  decl  } 

C  program_component  } 

"begin" 

seq_of_stmts 

"end"  [  identifier  ]  ";" 


Figure  4-1  Function  Body  Syntax 


procedure  FUNC_BODY (node  :  tree_node) ; 

var  child  :  tree_node; 
begin 

child  :=  f irst_child (node) ; 

FUNC_SPEC (child) ; 
child  :=  right_sibling (child) ; 
while  (node_type (child)  =  "decl") 
begin 

DECL (Child) ; 

child  :=  right_sibling (child) ; 

end; 

while  (node_type (child)  =  "program_component ) 
begin 

PROG_COMP (child) ; 

child  :=  right_sibling (child) ; 

end ; 

SEQ_OF_STMTS (child) ; 
child  :=  right_sibling (child) ; 
if  (node_type (child)  =  "identifier") 
old_ident (child) ; 

end ; 


Figure  4-2  Function  Body  Accepting  Procedure 

Required  non-terminals  like  func_spec  and 
seq_of_stmts  are  processed  by  their  own  functions.  The 
decl  and  prog_comp  repeaters  are  processed  in  while  loops 
for  as  many  such  nodes  as  exist  in  the  func_body.  The 
optional  identifier  at  the  end  of  the  func  body  is 
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processed  by  an  if  statement.  Unestablished  optionals  and 
repeaters  are  ignored  since  the  program  is  correct  without 
them . 

4.1.2  ALTERNATION  NODES 

An  alternation  non-terminal  is  processed  by  a  case  or 
switch  construct.  The  case  is  based  on  the  type  of  the 
non-terminal's  only  child.  One  case  is  used  for  each 
possible  alternative.  If  no  child  exists  due  to  an 
unestablished  alternative,  the  incomplete  program  fragment 
is  reported  as  an  error. 

4.1.3  SIMPLE  NON-TERMINALS 

A  third  type  of  non-terminal  exists  in  the  subset. 
This  is  a  non-terminal  that  is  replaced  by  a  single 
non-terminal.  These  non-terminals  are  processed  by  a 
simple  call  to  the  function  that  processes  the  second 
non- terminal .  For  example 

stmt  = 

simp_stmt  ; 

This  is  processed  by  the  function 

function  stmt (node  :  tree_node)  return  integer; 
begin 

stmt  :=  simp_stmt ( son (node) )  ; 
end; 
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This  has  several  causes.  In  the  above  example  the 
subset  eliminated  an  optional  label  from  the  production. 
The  production  was  left  as  is  to  allow  easier  expansion  of 
the  subset  to  the  full  Ada  grammar.  The  full  Ada  stmt  is 

stmt  = 

[  label  3  simp_stmt  ; 

Another  cause  is  shown  in  the  definition  of  a  proc_decl. 

proc_decl  = 

proc_spec_semi  ; 

This  is  actually  an  alternation  in  the  full  Ada  grammar. 
Once  again  no  reduction  was  made  to  allow  for  easier 

expansion  of  the  compiler.  The  full  production  is 

proc_decl  = 

<  proc_spec_semi 
generic_proc_decl 
generic_proc_instant  >  ; 

4.1.4  COMPILATION  IN  PIECES 

Since  the  entire  tree  is  available  during  the 

complete  compilation  process,  it  need  not  be  accessed  in  a 
strict  linear  fashion  just  described.  It  could  be 

compiled  in  pieces  with  each  completed  subtree  being  pass 
by  the  editor  to  the  appropriate  subroutine  for 
processing.  This  would  allow  the  compiler  to  run 
background  to  the  editor,  which  would  improve  the 

efficiency  of  the  entire  system. 
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4.2  ERROR  HANDLING 

The  syntax  directed  editor  ensures  the  syntactic 
correctness  of  the  program  .  It  is  still  possible  for  the 
program  to  contain  semantic  errors.  It  is  the  compiler's 
responsibility  to  detect  and  report  these  errors.  Two 
examples  of  semantic  errors  are  an  undeclared  identifier 
and  an  identifier  of  the  wrong  type  in  an  expression. 


4.2.1  ERROR  RECOVERY 

Error  recovery  is  usually  a  difficult  process  for  a 
compiler,  since  it  is  trying  to  check  the  syntax  as  well 
as  the  semantics  of  a  program.  When  it  encounters  what  it 
thinks  is  an  error  it  must  check  if  using  a  different 
syntax  would  eliminate  the  error.  Also  the  recovery 
process  itself  may  cause  new  errors  to  be  detected  since 
the  compiler  must  guess  where  to  restart  the  compiling 
process . 

Due  to  the  assured  syntactic  correctness  of  the 
program,  the  error  recovery  function  is  all  but 
eliminated.  Semantic  errors  are  easy  to  recover  from, 
since  they  tend  to  only  affect  a  relatively  small  part  of 
the  entire  program.  The  recovery  process  involves 
patching  the  code  that  is  generated,  reporting  the  error 
to  the  user,  and  marking  the  erroneous  node.  Marking  the 
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node  allows  the  syntax  directed  editor  to  detect  it  as 
erroneous  and  move  the  focus  to  that  node  to  allow  the 
programmer  to  make  the  necessary  correction. 

The  fact  that  an  error  was  encountered  is  also  passed 
back  up  the  tree  through  the  returns  from  subroutine  calls 
until  a  subroutine  is  found  that  can  continue  in  spite  of 
the  error.  Thus  error  recovery  is  built  right  into  the 
functions  themselves  and  poses  no  particular  problems 
except  how  to  determine  when  an  error  no  longer  has  an 
affect . 

For  example  if  the  symbol  table  is  searched  for  an 
identifier  and  it  is  not  found,  the  error  undeclared 
identifier  is  generated.  This  error  only  affects  the 
expression  in  which  the  identifier  is  being  used.  The 
compiler  reports  the  error  and  then  generates  code  to  load 
a  0  value  instead  of  the  real  value  and  processing  is 
allowed  to  continue.  By  generating  this  code,  execution 
of  the  program  could  actually  take  place  although  the 

results  would  probably  be  invalid.  This  example  might 
result  in  the  expression  being  of  the  wrong  type  and 
further  errors  reported. 


4.3  SYMBOL  TABLE 

The  symbol  table  is  used  by  the  compiler  to  store 
information  about  the  names  in  the  program.  As 
implemented  the  names  are  left  in  the  abstract  syntax  tree 
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and  a  pointer  to  the  identifier  node  is  stored  in  the 
symbol  table.  The  characters  of  the  name  are  distributed 
as  children  of  the  identifier  node.  Comparison  of  two 
identifiers  is  done  by  pattern  matching  the  two  identifier 
subtrees.  This  leaves  the  storage  for  names  in  the  syntax 
tree  and  conserves  memory  since  an  identifier  is  stored  in 
only  one  place. 

4.3.1  SYMBOL  TABLE  STRUCTURE 

The  symbol  table  structure  is  one  area  that  required 
major  revisions  to  do  the  desired  expansions.  The  symbol 
table  data  structure  was  revised  to  hold  much  more 
information  about  a  symbol.  This  was  required  since  new 
types  were  introduced  and  functions  were  allowed.  Also 
fields  were  added  to  allow  parameters  for  functions  and 
procedures  and  to  allow  overloading  to  be  implemented  at  a 
later  date. 

The  symbol  table  is  implemented  as  an  array.  This  is 
a  simple  method  that  allowed  for  easy  implementation  of 
packages.  An  array  of  integers  is  very  easy  to  read  and 
write  to  disk  to  allow  the  visible  part  of  a  package  to  be 
saved  when  it  is  compiled  and  then  read  back  in  when  it  is 
used.  This  saving  of  the  symbol  table  is  necessary  to 
avoid  the  necessity  of  recompiling  the  package  each  time 
it  is  used.  This  reading  and  writing  of  the  symbol  table 
is  the  main  extension  to  the  symbol  table  that  was 
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implemented. 

The  new  data  structure  is  shown  in  Appendix  D.  A 
discussion  detailing  the  use  of  each  field  will  also  be 
found  there. 

4.3.2  SYMBOL  TABLE  ROUTINES 

The  symbol  table  routines  did  not  require  any  major 
modifications  since  overloading  was  not  implemented. 
Overloading  would  require  the  lookup  routine  to  find  all 
visible  occurrences  of  an  identifier.  These  would  be 
linked  together  and  passed  back  to  the  compiler.  Since 
overloading  is  not  allowed  only  the  first  occurrence  of  an 
identifier  is  found  and  the  symbol  table  index  is 

returned . 

4.4  CODE  GENERATION 

The  code  generated  by  the  compiler  is  for  a 
pseudo-machine  similar  to  the  PL/0  interpreter  written  by 
Niklaus  Wirth  (Ref  18) .  Code  is  generated  as  the  compiler 
walks  the  tree.  Each  instruction  generated  contains  a 
pointer  to  the  abstract  syntax  tree  node  which  is  thought 
to  be  responsible  for  the  instruction.  This  pointer  is 
used  by  the  interpreter  to  dynamically  show  the  programmer 
what  part  of  the  program  is  being  executed. 
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4.5  THE  INTERPRETER 

The  interpreter  can  be  called  by  the  syntax  directed 
editor  or  executed  independently.  The  interpreter  calls 
the  compiler  to  compile  the  program  and  if  no  errors  are 
detected  the  program  is  executed.  Using  the  information 
in  the  code  element,  the  interpreter  is  able  to  highlight 
the  program  tree  display  to  show  where  in  the  program 
execution  is  currently  occurring.  The  highlighted  portion 
of  the  tree  moves  around  as  instructions  are  executed  to 
trace  program  execution.  The  interpreter  also  displays 
the  top  few  elements  of  the  run  time  stack  and  the  next 
instruction  to  be  executed. 

4.5.1  MODIFICATIONS  TO  THE  INTERPRETER 

The  interpreter  required  several  revisions  to  get  it 
to  run  on  the  Vax  11/780.  These  revisions  were  due  mainly 
to  differences  in  the  way  the  micro-computer  operating 
system  required  space  to  be  allocated  and  the  way  the  Vax 
required  it. 

Code  for  some  of  the  pseudo-instructions  of  the  run 
time  machine  had  to  be  modified  to  accommodate  differences 
in  the  way  the  two  computers  and  their  C  compilers  handled 
expressions.  For  example  the  _SUB  instruction  was  coded 

push (-pop ( )  +  pop ( ) ) 

This  seems  to  be  correct  but  the  result  of  execution  as 
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shown  by  running  a  program  with  a  subtraction  in  it  was 

incorrect  on  the  Vax.  The  code  was  changed  to 

i  =  -pop ( ) ; 
j  =  pop() ; 
push ( i  + j )  ; 

This  code  seems  to  do  the  exact  same  function  but  the 
results  of  the  two  are  different.  The  first  set  of  code 
actually  gives  the  negative  of  the  correct  answer.  The 
second  set  of  code  gives  the  correct  answer.  The  reason 
is  unknown  but  probably  lies  in  a  different  implementation 
of  the  C  compilers  used  on  the  two  machines.  The  code  to 
evaluate  the  relational  instructions;  LES,  LEQ,  GRT,  GEQ; 
were  also  changed  in  this  manner. 

They  were  changed  in  this  manner  rather  than  directly 
manipulating  the  stack  in  order  to  ensure  stack  integrity 
by  using  the  stack  manipulation  functions,  push  and  pop. 
Another  method  that  could  have  been  used  was  to  change  the 
operator  being  used  in  the  interpreter.  Thus  SUB 
instruction  would  have  become 
(push (pop ( )  -  pop ( ) ) ; 

This  would  not  be  portable  to  other  machines  nor  would  it 
be  clear  as  to  why  the  apparent  order  of  evaluation  was 
changed.  To  avoid  this  ambiguity,  this  method  was  not 
used. 

The  other  changes  that  were  made  to  the  interpreter 
involved  the  addition  of  instructions  to  handle  the  new 
statement  forms  added  to  the  subset. 
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4.6  CURRENT  IMPLEMENTATION  AND  EXTENSIONS 

The  compiler  as  implemented  by  Scott  Ferguson  was  for 
a  limited  subset  of  Ada.  Various  extensions  and 
modifications  were  made  to  this  subset.  The  extensions 
include  new  predefined  operators  and  functions.  The 
modifications  to  the  current  compiler  were  done  to  allow 
predefined  data  types  other  ‘•'.an  integer  to  be  used. 

4.6.1  BOOLEAN  OPERATORS 

The  new  predefined  boolean  operators  added  to  the 

compiler  are  the  AND__THEN ,  OR_ELSE ,  and  XOR.  The  AND_THEN 

and  OR_ELSE  presented  several  problems  in  their 

implementation.  Though  the  implementation  is  similar  to 

the  other  Boolean  operators  in  form,  they  had  to  generate 
code  much  differently  since  their  intent  is  as 

short-circuit  operators. 

The  AND_THEN  operator  must  evaluate  its  left  operand 
and  if  it  has  a  value  of  true  the  right  operand  is 
evaluated.  If  the  value  is  false  then  the  right  operand 
is  not  evaluated. 

Similarly  the  OR_ELSE  operator  must  evaluate  its  left 
operand  and  if  the  value  is  false  it  must  evaluate  the 
right  operand.  If  the  value  is  true  then  the  right 
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locations  of  the  instructions  be  saved  until  the  entire 
expression  is  evaluated  so  that  the  code  can  be  fixed  to 
jump  to  the  correct  location. 

This  was  done  by  creating  two  new  instructions  for 
the  interpreter,  _AND_THEN  and  _OR_ELSE.  The  code  was 
also  generated  one  node  higher  in  the  tree  than  for  the 
other  Boolean  operators.  This  allowed  the  locations  for 
the  branching  instructions  to  be  linked  together  and  then 
fixed  after  the  expression  was  fully  analyzed.  See 
Appendix  E  for  the  code. 

4.6.2  INTEGER  OPERATORS 

The  other  new  predefined  operators  added  were  REM  and 
MOD.  These  were  rather  easy  to  include  in  the  compiler 
since  they  only  involved  adding  new  case  values  to 
existing  functions.  They  did  cause  some  problems  for 
inclusion  in  the  interpreter  since  C  does  not  have  a  REM 
function.  This  meant  code  for  the  REM  function  had  to  be 
written.  After  some  experimentation  using  the  examples  in 
the  Ada  reference  manual  (Ref  7) ,  a  formula  was  devised  to 
calculate  the  correct  value.  See  Appendix  E  for  the  code. 

4.6.3  SUBPROGRAMS 

The  AdaO  subset  included  only  procedures.  The  Adal 
subset  was  expanded  to  include  functions  as  well.  This 
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expansion  required  the  code  used  to  analyze  and  compile 
procedures  to  be  changed  because  the  AdaO  subset  did  not 
have  a  return  statement.  Since  Ada  requires  all  functions 
are  required  to  have  at  least  one  return  statement,  the 
return  statement  had  to  be  added  to  the  Adal  grammar. 
Since  the  code  required  to  handle  functions  and  procedures 
is  very  similar  they  are  discussed  together. 

Functions  were  rather  easy  to  include  in  the  extended 
compiler  because  a  function  is  essentially  a  procedure 
which  returns  a  value.  Procedures  were  already  included, 
so  the  extension  amounted  to  modifying  existing  code  to 
fit  the  function  syntax.  It  is  the  returning  of  a  value 
that  requires  the  use  of  a  return  statement. 

The  code  to  compile  a  procedure  also  had  to  be 
changed  to  accommodate  the  return  statement.  Two  changes 
were  made.  The  first  was  to  indicate  a  procedure  was 
being  compiled.  The  other  was  to  fix  the  code  generated 
by  the  return  statements.  Since  procedures  do  not  require 
a  return  statement  no  code  was  written  to  verify  the 
existence  of  a  return  statement  only  to  fix  the  code 
generated  if  any  exist. 

The  return  statement  caused  most  of  the  problems, 
mainly  because  it  could  appear  anywhere  in  the  body  of  a 
function  or  procedure.  These  problems  included 
determining  the  type  of  subprogram  currently  iseing 
compiled,  where  to  put  the  value  being  returned,  how  to 
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verify  its  type,  and  how  to  link  the  return  statements  to 
the  end  of  the  subprogram  so  that  the  stack  clean  up  steps 
could  be  done  properly. 

4. 6. 3.1  SUBPROGRAM  RETURN 

When  the  return  statement  is  compiled  it  is  necessary 
to  know  if  the  return  is  from  a  function  or  a  procedure 
since  a  function  return  must  include  an  expression  while 
the  procedure  return  return  cannot. 

Since  the  return  statement  can  only  appear  within  the 
statement  body  and  the  type  of  the  statement  body  cannot 
change  until  the  body  is  complete,  an  external  pointer  can 
be  used.  An  external  symbol  table  pointer  is  set  to  point 
to  the  name  of  the  current  function  or  procedure  being 
compiled.  The  pointer  is  set  just  before  the  body  is 
compiled.  When  a  return  statement  is  encountered  the 
subprogram  type  of  this  name  is  checked  to  see  if  a 
function  or  procedure  is  being  compiled.  Appropriate 
actions  are  taken  in  each  case.  The  code  to  handle  a 
return  statement  is  shown  in  Appendix  E. 


4. 6. 3. 2  VALUE  RETURN  FROM  A  FUNCTION 

The  problem  of  how  to  save  a  value  being  returned 
from  a  function  was  also  rather  easy  to  solve.  The 
calling  routine  expects  the  value  to  be  on  top  of  the 
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stack  when  the  return  is  made  therefore  code  was  generated 
to  ensure  the  value  being  returned  appeared  where  it  was 
expected.  The  solution  involved  a  two  step  process  and  is 
limited  to  handling  simple  data  types.  The  solution  can 
be  easily  expanded  to  handle  more  complex  data  types  but 
since  they  were  not  in  the  subset  the  extensions  were  not 
made . 

The  first  step  was  to  create  a  stack  entry  for  the 
return  value  before  the  function  was  actually  called. 
This  ensured  the  value  would  appear  on  top  of  the  stack 
upon  return  and  it  allows  the  function  to  do  its  normal 
stack  clean  up  with  out  worrying  about  what  to  do  with  the 
returned  value.  This  is  done  by  loading  a  0  value  onto 
the  stack.  To  expand  this  to  data  structures  a  0  could  be 
loaded  for  each  element  of  the  structure. 

The  second  step  was  to  store  the  value  into  this 
location.  This  location  is  a  -4  offset  from  the 

function's  stack  base.  Thus  a  store  instruction  with 
offset  -4  is  generated  just  before  the  stack  ’clean  up  and 
subprogram  return  instructions  are  generated.  To  expand 
this  to  handle  data  structures  a  similar  store  instruction 
could  be  issued  for  each  element  of  the  structure. 

Several  problems  with  this  method  exist.  These  are  a 
function  return  statement  that  does  not  return  a  value, 
return  to  the  operating  system,  and  return  type 
validation.  These  problems  were  handled  rather  easily. 
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A  function  return  statement  that  does  not  return  a 

value  is  in  error  and  must  be  reported  as  such.  This  is 

handled  quite  easily  but  the  user  may  want  to  allow 
execution  to  occur  in  spite  of  the  errors.  Partial 

execution  is  possible  and  if  the  statement  which  caused 

the  errors  is  not  executed  the  program  may  actually  give 
correct  results.  To  allow  partial  execution  to  occur  an 

instruction  is  generated  to  put  a  value  onto  the  stack  in 

place  of  the  value  that  is  expected.  The  value  used  is  0 
but  to  cause  termination  the  undefined  value  could  be 

used.  Another  solution  would  be  to  generate  an  abort 

statement  with  an  appropriate  error  message. 

To  allow  return  to  the  "operating  system"  the 

interpreter  was  modified  to  push  an  extra  0  onto  the  stack 
to  account  for  the  value  being  returned  by  a  function. 

This  can  occur  when  a  function  is  being  written  as  a 

separate  entity  to  be  used  by  several  programs.  Though  no 
method  of  separate  compilation  is  implemented,  a  function 
could  be  written  and  tested  independently  with  this 

change . 

The  third  problem  is  type  validation  of  the  value 
being  returned.  The  type  must  be  checked  when  the 
expression  is  compiled  and  its  type  is  known.  The 

solution  is  discussed  in  the  next  section. 
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4. 6. 3. 3  RETURN  TYPE  VALIDATION 

The  type  validation  problem  is  also  rather  easy  to 
solve.  It  is  actually  a  two  part  problem.  The  first  part 
is  handled  by  the  compiler  to  check  that  the  expression  is 
of  the  correct  type.  The  second  must  be  handled  by  the 
interpreter  to  verify  the  value  being  returned  is  in  the 
correct  range  for  a  subtype. 

The  compiler  can  do  its  checking  using  the  symbol 
table  pointer  discussed  earlier.  This  pointer  gives 
access  not  only  to  the  functions  name  but  also  t  the  type 
it  must  return.  Using  the  pointer  the  expected  and  actual 
types  are  compared.  If  they  are  the  same  the  type  is 
returned.  If  not  an  error  message  is  generated  and  error 
is  returned.  This  problem  will  be  handled  by  the  semantic 
analyzer  when  it  is  implemented. 

The  problem  of  range  checking  is  handled  by  the 
interpreter  and  was  not  implemented  since  subranges  were 
not  in  the  subset.  The  solution  is  rather  easy  and  is 
given  now.  The  compiler  must  generate  code  to  load  the 
upper  and  lower  bounds  of  the  range  onto  the  stack  and  an 
instruction  to  cause  the  value  to  be  checked.  The 
interpreter  must  then  execute  these  instructions  and  leave 
the  value  on  the  stack  if  it  is  in  the  range  or  generate  a 
run  time  error  if  it  is  not  in  the  range. 
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4. 6. 3. 4  LINKING  THE  RETURN  TO  THE  END  OF  THE  SUBPROGRAM 

Linking  the  return  statements  to  the  end  of  the 
subprogram  was  the  most  difficult  problem  to  solve.  Two 
potential  solutions  were  investigated. 

The  first  potential  solution  is  to  generate  the  code 
to  do  the  stack  clean  up,  subprogram  return  and  value 
store  each  time  a  return  statement  is  compiled.  This  is 
easy  to  do  but  requires  the  symbol  table  to  be  modified  to 
hold  the  number  of  names  declared  in  the  subprogram.  It 
also  requires  2  or  3  instructions  to  be  generated  for  each 
return  statement. 

The  other  method  is  to  generate  a  jump  instruction  to 
transfer  control  to  the  end  of  the  subprogram  where  stack 
clean  up,  subprogram  return,  and  value  store  will  be  done. 
This  requires  the  compiler  to  do  some  extra  work  since  the 
jump  instructions  must  be  linked  together  to  allow  them  to 
be  fixed  when  the  subprogram  end  is  found.  This  requires 
the  compiler  to  keep  a  list  of  the  jump  instructions.  The 
jump  instructions  themselves  can  be  used  for  this  purpose 
since  the  operand  fields  are  not  used  until  the 
instruction  is  fixed.  Only  a  single  new  variable  is 
needed  to  keep  track  of  the  return  list.  This  variable  is 
needed  anyways  to  indicate  whether  a  subprogram  has  a 
return  statement  or  not. 

Since  the  second  method  was  rather  easy  to  implement 
and  required  less  memory  for  a  subprogram  with  more  than 
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one  return  statement  it  was  chosen.  See  Appendix  E  for 
the  code  written  to  implement  these  features. 


4.6.4  DATA  TYPES 

The  modifications  to  the  AdaO  compiler  to  allow  new 
types  to  be  added  were  quite  extensive.  The  AdaO  compiler 
uses  functions  that  return  one  of  four  possible  values, 
SUCCESS,  ERROR,  a  symbol  table  index,  and  a  value.  Only 
functions  that  returned  SUCCESS  had  to  be  changed,  to 
return  a  type  value.  Code  also  had  to  be  added  to  verify 
the  returned  type  was  alright  in  the  context  it  appeared. 

For  example  in  the  if_statement  the  expression  must 
be  a  boolean  expression.  The  syntax  for  expression  allows 
any  type  expression  to  be  entered  so  the  expression 
analyzer  had  to  be  changed  to  return  a  type  and  the 
if_statement  analyzer  had  to  test  that  type.  A  full  list 
of  the  modified  functions  is  shown  in  Appendix  xx. 

A  simple  semantic  analyzer  was  embedded  in  the 
compiler.  It  allowed  type  checking  but  could  not  handle 
the  problems  of  overloading.  This  approach  was  used  since 
a  separate  semantic  analyzer  will  be  almost  as  large  as 
the  compiler  itself  and  when  it  is  written  it  should  take 
overloading  into  account  and  solve  the  problems 
overloading  causes.  Since  overloading  was  not  allowed  in 
the  Adal  subset,  this  problem  was  not  c -dressed  except  to 
design  a  mechanism  to  handle  overload  resolution.  That 
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design  is  presented  in  the  next  chapter. 


4.6.5  OTHER  MODIFICATIONS 

Other  modifications  had  to  be  made  to  the  compiler. 
These  involved  differences  in  how  the  micro-computer  which 
Ferguson  used  and  the  VAX  11/780  do  things.  These  changes 
were  minor  but  difficult  to  pin  down  since  they  did  not 
appear  until  the  compiler  was  actually  being  tested.  The 
main  area  of  concern  was  how  memory  is  dynamically 
allocated  to  a  program.  The  way  Ferguson  had  allocated 
memory  to  the  AdaO  compiler  should  have  worked  on  both 
systems  but  it  did  not.  The  compiler  did  not  catch  the 
problem  since  it  was  not  a  syntax  or  semantic  error  but  a 
difference  in  how  the  functions  involved  were  implemented. 
This  is  a  prime  example  of  how  a  standardized  language  and 
implementation,  like  Ada,  would  have  saved  time  and 
effort . 

The  second  change  was  in  how  tlK  various  tools  of  the 
environment  called  each  other.  This  again  was  not  caught 
until  the  system  was  tested  as  a  whole.  The  problem  was 
in  the  function,  EXECL ,  which  used  its  arguments 
differently  on  the  two  systems.  Again  the  change  was 
minor  but  still  a  change  that  should  not  have  been 
necessary.  To  complicate  matters  neither  system 

documented  their  usage  well  and  the  changes  had  to  be  made 
through  experimentation. 
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The  third  area  of  change  was  due  to  changes  in  the 
Ada  syntax  as  presented  in  the  Ada  standard  (Ref  6).  The 
Ada  grammar  was  changed  in  several  subtle  areas  between 
the  preliminary  Ada  reference  grammar  (Ref  7)  which  Scott 
Ferguson  used,  and  the  Ada  standard  which  I  had  to  follow. 
Most  of  the  changes  were  in  areas  that  did  not  affect  this 
thesis  effort,  but  one  change  did. 

This  change  is  the  introduction  of  a  new  level  of 
precedence  for  operators,  the  highest  precedence 
operators.  The  newly  defined  highest  precedence  operators 
are  an  exponentiation  operator,  the  NOT  operator,  and  an 
absolute  value  operator,  ABS.  In  the  preliminary 
reference  grammar  the  NOT  operator  was  defined  as  a  unary 
operator,  while  the  other  two  were  not  defined  at  all. 
The  NOT  and  ABS  operators  are  unary  operators  but  they  are 
given  a  higher  precedence  than  the  other  unary  operators 
defined  in  the  Ada  grammar.  This  change  in  precedence 
required  several  changes  to  the  grammar  and  changes  to  the 
compiler  to  handle  the  new  syntax. 


DESIGN  OF  THE  NEW  TOOLS 

5.0  DESIGN  OF  THE  NEW  TOOLS 

Several  new  tools  were  designed  as  a  result  of  this 
thesis  effort.  The  original  intent  was  to  also  do  the 
implementation  of  these  tools  but  time  limitations  made  this 
impossible . 

The  new  tools  designed  are  a  semantic  analyzer,  a 
method  for  passing  parameters  to  subprograms,  and  data 
structures  to  allow  user  defined  data  types. 


5.1  SEMANTIC  ANALYZER 

A  semantic  analyzer  is  needed  to  resolve  overloading  of 
names  in  Ada.  Languages  like  Pascal  do  not  need  a  separate 
semantic  analyzer  because  names  cannot  be  overloaded  as  they 
can  in  Ada.  A  simple  symbol  table  search  is  all  a  Pascal 
compiler  needs  to  do  since  only  one  instance  of  a  name  is 
visible  at  anytime.  Either  a  name  is  in  the  symbol  table  or 
it  is  not  and  the  compiler  does  its  analysis  accordingly. 
An  Ada  compiler  must  also  consider  the  context  in  which  a 
name  appears  because  all  instances  of  a  name  are  potentially 
visible . 

Since  this  analysis  can  be  quite  complicated  a  separate 
analyzer  is  proposed  and  designed. 
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5.1.1  THE  BASIC  SEMANTIC  ANALYSIS  ALGORITHM 

The  semantic  analyzer  is  called  by  the  compiler  when 
the  compiler  needs  to  know  the  type  of  an  expression.  The 
compiler  passes  the  root  node  of  the  expression  to  the 
semantic  analyzer.  The  semantic  analyzer  uses  this  node  as 
the  root  of  the  tree  it  must  analyze.  The  semantic  analyzer 
walks  this  tree  much  like  the  compiler  would  and  determines 
the  type  of  each  component  of  the  tree. 

The  analysis  takes  place  in  three  phases  or  passes. 
This  is  all  the  analyzer  requires  to  analyze  and  completely 
type  an  expression  (Ref  2).  This  analysis  will  result  in 
either  a  valid  expression  with  each  node  of  the  tree  being 
typed  or  an  invalid  expression.  An  invalid  expression  is 
one  that  either  does  not  have  a  valid  interpretation  or  has 
more  than  one  valid  interpretation. 

5. 1.1.1  PASS  ONE 

The  first  pass  is  a  top  down  pass  that  hangs  the 
desired  types  onto  each  node  of  the  tree.  This  is  done  by 
analyzing  expression  beginning  with  the  operator  that  will 
be  executed  last.  This  operator  is  the  rightmost  operator 
with  the  lowest  precedence  in  the  expression.  Since  the 
tree  being  analyzed  is  an  operator  precedence  tree  the 
rightmost  operator  at  this  level  in  the  tree  is  chosen.  The 
operator  is  analyzed  and  right  and  left  operand  lists  are 
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developed  for  it.  If  either  of  these  lists  is  empty  an 
error  is  reported  and  analysis  can  stop.  If  both  lists  are 
non-empty  they  are  passed  to  recursive  calls  to  pass  one  to 
analyze  the  operands  as  expressions  themselves.  This 
process  continues  until  a  leaf  node  is  reached  at  which  time 
pass  two  is  called. 

5 . 1 . 1 . 2  PASS  TWO 

The  second  pass  is  a  bottom  up  pass  that  delivers  the 
available  types  for  an  expression  based  on  the  types 
available  in  the  tree  below.  These  available  types  are 
compared  with  the  list  of  desired  types  for  the  node  and  a 
new  list  is  created.  This  new  list  consists  of  the  types 
that  are  on  both  the  available  list  and  the  desired  list. 
If  this  list  is  empty  an  error  is  reported  and  analysis  con 
stop.  If  the  list  is  non-empty,  it  is  hung  on  the  node 
replacing  the  desired  list  and  it  is  passed  back  up  the  tree 
to  the  expression  above.  This  process  continues  until  the 
root  node  of  the  expression  is  reached  at  which  time  two 
possible  results  can  occur,  a  single  valid  type  or  the 
expression  has  multiple  valid  types. 

If  the  expression  has  a  single  valid  type  pass  three  is 
run  to  resolve  any  ambiguities  that  still  appear  in  the 
tree.  If  the  expression  has  more  than  one  valid 
interpretation  an  error  is  reported  and  analysis  is  stopped. 
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This  is  the  only  point  at  which  multiple  valid 

interpretations  cause  an  error  to  be  reported. 

5. 1.1. 3  PASS  THREE 

The  third  pass  is  another  top  down  pass  that  must 
resolve  any  remaining  ambiguities.  Pass  two  could  be 
written  to  indicate  that  no  ambiguities  appear  below  a  given 
node  thus  making  analysis  by  pass  three  unnecessary.  If  at 
any  time  during  this  pass  an  ambiguity  cannot  be  resolved 
the  expression  is  invalid  and  an  error  must  be  reported.  No 
further  analysis  will  resolve  the  ambiguity  since  previous 
analysis  has  shown  the  interpretations  to  be  valid  and  no 
new  restrictions  have  been  introduced. 

5.1.2  DATA  STRUCTURES  USED 

The  semantic  analyzer  requires  two  different  data 
structures  to  do  its  analysis.  Both  structures  are  linked 
lists  but  their  contents  are  somewhat  different. 

5.1.2 .1  OPERAND  LIST 

The  first  structure  is  the  operand  list.  This  list 
contains  the  currently  valid  type  or  types  for  the  operand 
or  name  in  question.  The  structure  consists  of  a  type  and  a 
pointer  to  the  next  element  of  the  list. 
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5. 1. 2.2  OPERATOR  LIST 

The  other  structure  is  the  operator  list.  This  list 
contains  the  currently  valid  interpretations  of  the 
operator.  This  structure  consists  of  five  elements.  The 
valid  type  for  the  left  operand,  the  corresponding  valid 
type  for  the  right  operand,  the  type  this  operator  will 
return,  the  symbol  table  index  of  the  operator,  and  a 
pointer  to  the  next  element  in  the  list. 

The  symbol  table  pointer  for  a  predefined  operator  is 
set  to  "-1".  This  is  because  the  operators  are  not  in  the 
symbol  table  but  will  be  recognized  by  the  code  generator 
from  the  types  of  the  operands.  This  will  also  save  time 
during  execution  since  no  function  call  is  made  to 
evaluate  the  operator. 

5.2  PARAMETER  PASSING 

Parameter  passing  to  functions  and  procedures  in  Ada 
can  be  extremely  complicated.  The  complications  result 
from  the  many  diverse  methods  of  passing  parameters  that 
are  allowed  in  Ada.  Ada  allows  parameters  to  be  in,  out, 
or  in  out  parameters.  They  can  be  passed  positionally,  by 
name,  by  default  value,  or  any  combination  of  the  three. 

Due  to  the  complex  nature,  a  full  parameter  passing 
mechanism  was  not  designed.  Only  positional  parameter 
passing  is  handled  but  the  mechanism  does  not  preclude 
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enhancement  to  handle  the  other  methods.  Positional 
parameter  passing  is  complicated  because  of  the  various 
modes  a  parameter  is  allowed  to  have. 

5.2.1  PARAMETER  MODES 

Parameters  in  Ada  can  be  given  one  of  three  modes. 
These  modes  are  IN,  OUT,  and  IN  OUT.  If  no  mode  is  given 
in  the  declaration  of  a  parameter  it  defaults  to  the  IN 
mode.  A  short  explanation  of  each  of  these  modes  is  given 
below. 

5. 2. 1.1  IN  PARAMETERS 

In  parameters  are  treated  as  local  constants  inside 
the  subprogram.  They  have  a  value  associated  with  them 
when  the  subprogram  is  called  and  they  cannot  be  updated 
by  the  subprogram. 

5. 2. 1.2  OUT  PARAMETERS 

Out  parameters  are  treated  as  local  variables  inside 
the  subprogram.  They  do  not  have  a  value  associated  with 
them  when  the  subprogram  is  called  but  they  are  allowed  to 
be  assigned  a  value.  In  fact  the  subprogram  is  considered 
to  be  in  error  if  an  assignment  is  not  made.  The  value 
associated  with  an  out  parameter  when  the  subprogram 
returns  is  copied  back  into  the  location  of  the  actual 
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parameter  that  was  used  in  the  call.  For  this  reason  an 
out  parameter  must  be  a  variable  name  and  not  an 
expression . 

5. 2. 1.3  IN  OUT  PARAMETERS 

In  out  parameters  are  also  treated  as  local  variables 
inside  the  subprogram.  They  do  have  an  initial  value 
associated  with  them  when  the  subprogram  is  called  and 
they  are  allowed  to  have  a  new  value  assigned  to  them 
during  the  execution  of  the  subprogram.  In  out  parameters 
do  not  have  to  be  updated  by  the  subprogram.  The  value  of 
an  in  out  parameter  is  also  copied  back  when  the 
subprogram  returns.  In  out  parameters  must  also  be 
variables  and  not  expressions. 


5.2.2  PARAMETERS  TO  FUNCTIONS 

Since  functions  are  not  allowed  to  produce  any  side 
effects  other  than  returning  a  value,  out  and  in  out 
parameters  are  not  allowed.  This  makes  functions 
relatively  easy  to  handle  since  each  parameter  must  have 
an  initial  value  and  that  value  is  then  pushed  onto  the 
stack.  The  compiler  must  make  certain  that  the  formal 
parameters  are  not  updated  or  used  as  out  or  in  out 
parameters  to  another  procedure.  This  is  relatively  easy 
since  the  parameters  will  be  marked  as  constants  and  the 
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compiler  ensures  that  a  constant  is  not  updated.  Also 

since  the  values  associated  with  the  parameters  are  not 
needed  after  the  function  returns  the  stack  can  be  cleaned 
up  by  the  function  return  and  the  returned  value (s)  left 
on  top  of  the  stack. 

5.2.3  PARAMETERS  TO  PROCEDURES 

It  is  procedures  that  cause  the  majority  of  problems 
since  they  are  allowed  to  have  out  and  in  out  parameters. 
In  parameters  are  treated  the  same  as  functions.  Their 

value  is  pushed  onto  the  stack  and  then  the  procedure 

references  it  from  there.  This  method  was  chosen  for  in 

parameters  since  the  value  is  known  when  the  function  is 
called  and  the  actual  parameter  can  be  an  expression  which 
the  run  time  machine  will  evaluate  and  leave  the  value  for 
it  on  top  of  the  stack.  Since  that  is  where  we  want  the 

value  to  be,  no  special  treatment  is  needed.  Also  if 

default  values  are  allowed  they  can  be  pushed  onto  the 
stack  if  the  actual  parameter  is  not  found  for  the  call. 

Out  parameters  cause  many  problems  of  their  own. 
Since  they  must  receive  a  value  during  execution  of  the 
subprogram  the  run  time  mechanism  must  be  changed  to 
verify  all  out  parameters  were  updated.  Perhaps  the 
easiest  way  to  do  this  is  to  reserve  one  bit  pattern  as  an 
undefined  value.  This  value  could  then  be  detected  by  the 

run  time  mechanism  if  it  was  ever  used  as  a  valid  value. 
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The  value  that  is  the  easiest  to  use  is  the  smallest 
negative  number  or  the  largest  positive  number.  This 
reduces  the  values  a  program  can  use  but  the  restriction 
is  easy  to  live  with  since  numbers  of  that  magnitude 
seldom  get  used  in  a  program. 

5.2.4  DATA  STRUCTURES  AS  PARAMETERS 

Structures  like  arrays  and  records  can  cause 
problems.  They  can  be  handled  in  two  ways.  The  first  is 
to  simply  push  all  the  values  onto  the  stack  and  reference 
them  from  there.  The  other  idea  is  to  push  a  pointer  at 
the  first  element  of  the  array  or  record  and  reference 
them  indirectly.  Both  methods  have  their  advantages  and 
disadvantages . 

Pushing  the  structure  onto  the  stack  has  the 
advantage  that  only  that  procedure  or  function  can  address 
that  copy  of  the  variable.  This  is  especially  useful  if 
the  structure  is  an  in  parameter  and  it  c&n  be  addressed 
globally  as  well.  The  standard  says  that  any  program  that 
does  that  is  in  error  since  a  "constant"  (the  formal 
parameter)  was  updated  during  execution  of  the  subprogram. 
The  handling  of  this  problem  seems  to  be  beyond  the  scope 
of  this  thesis  effort  and  was  not  addressed. 

The  other  problem  that  can  arise  is  if  the  actual 
parameter  is  visible  to  more  than  one  concurrently 
executing  task.  In  this  case  the  indirect  method  could 
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produce  varying  results  depending  on  how  quickly  each  task 
executed.  In  this  case  the  program  is  also  in  error. 
Since  tasks  were  not  included  in  the  Adal  subset,  this 
problem  was  not  addressed. 

Pushing  all  values  onto  the  stack  has  its  drawbacks 
as  well  since  it  "wastes"  stack  space.  With  a  limited 
stack  this  could  present  a  problem  for  a  large  program. 
Access  through  indirection  does  not  have  this  problem  but 
it  does  have  the  problems  discussed  in  the  previously. 
Since  the  former  problem  is  much  more  difficult  to  solve 
than  running  out  of  stack  space,  the  method  of  pushing  all 
values  onto  the  stack  was  chosen.  If  programs  are  written 
that  exhaust  the  stack  space,  the  user  must  simply 
recompile  the  interpreter  and  increase  the  stack  space  or 
rewrite  the  stack  handler  to  allow  linked  stacks. 

5.2.5  PROPOSED  SOLUTIONS 

The  Ada  standard  (Ref  6)  does  not  specify  how  out  and 
in  out  parameters  are  to  be  handled.  They  can  either  be 
passed  by  value  (undefined)  and  then  update  the  actual 
parameter  when  the  procedure  is  complete  or  they  can  be 
passed  by  reference  and  be  updated  as  the  procedure 
executes.  To  avoid  some  of  the  other  problems,  pass  by 
value  and  update  on  return  was  chosen. 

Structures  and  simple  names  present  no  real  problems 
and  are  handled  easily.  This  is  because  their  addresses 
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are  known  at  compile  time  and  the  code  to  do  the  load  and 
update  can  be  generated  correctly.  The  parameters  that 
cause  problems  are  the  indexed  names  like  a  single  array 
element.  Since  the  index  is  allowed  to  be  an  expression 
whose  value  is  not  known  until  execution,  the  location  to 
update  is  not  known  until  run  time.  This  is  no  problem 
for  the  call  but  only  for  the  return. 

5. 2. 5.1  INDEX  RE-EVALUATION 

The  first  method  that  comes  to  mind  is  to  evaluate 
the  expression  and  push  the  value  onto  the  stack  then  load 
the  value  using  the  index  to  get  the  value  to  be  passed. 
For  the  return  the  same  expression  can  be  re-evaluated  and 


the  index 

used 

for 

the  store  instruction. 

That  looks  ■ 

good 

but  what 

if 

value 

of  the  expression 

for  the  index 

has 

changed . 

This 

can 

happen  if  one  of  the 

variables  in 

the 

expression 

is 

used 

as  an  out  or  in  out 

parameter  to 

the 

procedure  or  if  it  is  used  globally  by  the  procedure. 
This  method  was  not  used. 

5. 2. 5. 2  INDEX  LEFT  ON  STACK 

The  second  method  that  came  to  mind  was  to  leave  the 
value  of  the  index  on  the  stack  after  the  load  and  then 


use  it  when  the  procedure  exits  and  the  new  value  is 
saved.  A  minor  problem  with  this  is  that  all  parameters 
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below  this  one  are  now  offset  one  too  many  and  the 
references  to  them  will  be  incorrect.  A  solution  seemed 
to  be  to  change  the  offset  value  in  the  symbol  table  but 
this  prevents  recursion  since  the  second  call  has  no  way 
of  saving  the  offset  values  from  the  first  call.  This 
method  was  not  used. 

5. 2. 5. 3  MODIFY  SYMBOL  TABLE 

A  third  method  that  was  investigated  was  to  add  the 
new  elements  to  the  symbol  table  and  then  have  the  run 
time  mechanism  reference  them  through  the  symbol  table. 
This  would  work  but  would  require  a  major  rewrite  of  the 
run  time  machine  and  the  symbol  table  handler.  For  these 
reasons  this  method  was  not  used. 

5. 2. 5. 4  USE  A  SECOND  STACK 

The  fourth  method  that  was  investigated  involved  the 
use  of  a  secondary  stack  by  the  run  time  machine.  The 
second  stack  is  used  to  save  the  index  values  for  out 
parameters.  It  is  only  used  when  a  procedure  is  invoked 
that  has  an  out  or  in  out  parameter (s)  and  the  actual 
parameter  used  in  the  call  is  an  indexed_compon  '•nt .  This 
required  a  minor  rewrite  of  the  run  time  machine  but  since 
several  new  instructions  were  being  added,  the  rewrite  was 
inevitable.  The  rewrite  does  not  change  any  of  the 
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instructions  currently  implemented  but  was  limited  to 
adding  code  to  interpret  the  new  instructions.  Since  no 
major  problems  were  found  with  this  solution,  it  was 
designed.  The  basic  algorithm  is  given  in  Appendix  C. 

This  is  a  workable  design  and  it  does  not  preclude  an 


extension 

to 

allow 

named 

parameter 

passing 

or 

default 

parameter 

values  to 

be 

used . 

This 

design 

also 

al lows 

recursion 

and 

seems 

to 

solve 

many 

of  the 

Ada 

related 

problems.  One  change  seems  necessary  to  this  algorithm. 
That  is  to  handle  overloading  of  names.  This  problem  is 
solved  by  using  the  semantic  analyzer  to  resolve  the 
ambiguities  and  only  use  this  algorithm  as  a  code 
generator  after  all  ambiguities  have  been  resolved.  The 
steps  that  verify  correct  types  and  number  of  parameters 
can  then  be  deleted  since  the  procedure  will  be 

semantically  correct  before  this  algorithm  is  used. 

5.3  DATA  STRUCTURES 

The  data  structures  to  implement  user  defined  data 
types  and  allow  for  package  elaboration  are  shown  in 
figure  5-1  and  5-2.  A  short  explanation  of  how  these 
structures  were  developed  and  how  they  are  used  is  given 
below. 


75 


DESIGN  OF  THE  NEW  TOOLS 


5.3.1  USER  DATA  TYPES 


The  user_data_type  structure,  shown  in  figure  5-1,  is 
used  to  store  information  about  a  user  defined  data  type. 
Eventually  all  data  types  will  be  "user  defined",  since 
the  package  standard  will  be  used  to  pre-load  the  symbol 
table  with  the  predefined  types  and  functions.  In  the 
current  implementation  the  predefined  types  and  functions 
are  handled  as  special  cases  by  the  compiler.  They  are 
recognized  and  handled  properly. 


struct 

( 

int 

user  data 

types 

name , 

/* 

pointer  to  name  in  tree 

*/ 

base  type, 

/* 

pointer  to  base  type 

*/ 

first. 

/* 

pointers  to  first  and 

*/ 

last , 

/* 

last  enumeration  lits 

*/ 

/* 

for  enumeration  types, 

*/ 

/* 

fields  for  records, 

*/ 

/* 

indices  for  arrays 

*/ 

index_type 

,  /* 

type  of  index  elements 

*/ 

num; 

/* 

number  of  values  for 

*/ 

/* 

enumeration  types. 

*/ 

/* 

size  of  an  array  or 

*/ 

/* 

record 

*/ 

unsigned  flags; 

/* 

binary  flags  explained 

*/ 

/* 

below 

*/ 

#def ine 

IS  ARRAY 

0x01 

/*  type  is  an  array 

*/ 

#def ine 

IS  RECORD 

0x02 

/*  type  is  a  record 

*/ 

#def ine 

IS  ENUM 

0x04 

/*  enumeration  type 

*/ 

#def ine 

INDEX  INT 

0x08 

/*  indices  are  integer 

*/ 

Figure  5-1 

User  Data  Type 
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5. 3. 1.1  NAME  FIELD 

The  name  field  is  a  pointer  back  to  the  node  that 
created  the  new  type.  The  children  of  this  node  are  the 
name  of  the  type.  This  is  done  to  allow  to  data  type 
names  to  be  compared  in  a  manner  similar  to  the  one  used 
to  compare  to  identifiers. 

5. 3. 1.2  BASE  TYPE  FIELD 

The  base_type  field  is  used  for  arrays  and  subtypes 
to  indicate  the  type  of  the  elements  of  the  array  or  the 
base  type  of  the  subtype.  Since  this  is  a  pointer  into 
the  abstract  syntax  tree,  it  is  possible  to  define  an 
array  of  arrays.  This  construct  is  left  as  illegal  in  the 
Adal  subset  but  since  this  is  how  Ada  defines  multiply 
subscripted  arrays,  extending  this  data  structure  should 
be  easy. 

5. 3. 1.3  FIRST  AND  LAST  FIELDS 

First  and  last  have  two  uses.  For  enumeration  types 
they  point  into  the  abstract  syntax  tree  to  indicate  the 
first  and  last  elements  of  an  enumeration  type.  For 
arrays  they  point  into  the  abstract  syntax  tree  to 
indicate  the  first  and  last  indices  of  an  array.  This  is 
unless  the  indices  are  integers  then  they  are  simply  the 
first  and  last  indices. 
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5. 3. 1.4  INDEX  TYPE  FIELD 

Index_type  is  used  for  arrays  to  indicate  the  type  of 
indices  the  array  uses.  This  is  also  a  pointer  into  the 
abstract  syntax  tree  to  allow  two  types  to  be  compared. 
If  the  indices  are  integers  this  field  is  set  to  -1. 

5. 3. 1.5  NUM  FIELD 

Num  also  has  two  uses.  For  enumeration  data  types 
and  subtypes  it  is  the  number  of  elements  in  the  type. 
For  structures  it  is  the  size  in  words  of  the  structure. 

5. 3. 1.6  FLAGS  FIELD 

The  flags  field  is  used  to  indicate  type  the  new  type 
is.  The  is_array  flag  is  set  if  it  is  an  array.  The 
is_record  is  set  for  records.  The  is_enum  bit  is  set  for 
enumeration  types.  The  int_index  is  set  if  the  indices 
for  an  array  is  a  range  of  integers. 

5.3.2  WITH  AND  USE  DATA  STRUCTURES 

The  with  and  use  data  structures,  shown  in  figure 
5-2,  are  used  for  package  elaboration.  When  a  with_clause 
is  found  in  the  abstract  syntax  tree  the  symbol  table  and 
code  for  the  package  must  be  read  in  from  secondary 
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storage.  Before  reading  them  in  a  search  of  the  with_list 
is  done  to  ensure  a  package  is  only  elaborated  once.  The 
current  environment  is  also  searched  to  ensure  the  package 
has  been  previously  compiled  and  the  symbol  table  and  code 
for  it  exist.  As  the  symbol  table  is  read  in  the 
addresses  of  all  procedures  and  functions  must  be  updated 
to  indicate  the  new  address  currently  being  used.  This  is 
very  easy  to  do  since  the  new  address  will  be  the  old 
address  plus  the  current  offset  in  the  code  array.  The 
new  package  name  is  added  to  the  with_list  and  processing 
continues . 


struct  with  list 


c 

int 

name , 

/* 

pointer 

to  package  name  in 

*/ 

/* 

syntax 

tree 

*/ 

first 

,  /* 

index  into  symbol  table  to 

*/ 

/* 

first  and  last  symbol  table 

*/ 

last; 

/* 

entries 

for  the  package. 

*/ 

struct  with 

_list 

*next ; 

/*  pointer  to  next 

*/ 

] 

/*  package  name 

*/ 

truct 

C 

int 

use__list 

name ; 

/* 

pointer 

to  package  name  in 

*/ 

/* 

the  syntax  tree 

*/ 

struct  use 

list 

*next; 

/*  pointer  to  next 

*/ 

/*  use  list 

*/ 

} 


Figure  5-2  With  and  Use  data  structures 


When  a  use  clause  is  encountered  the  with  list  is 


checked  for  the  name  of  the  package.  If  it  is  not  found 
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an  error  is  reported  since  a  with_clause  for  that  package 
must  precede  the  use_clause.  If  found  the  current 


use_list  is 

searched 

to 

see  if  the 

package 

is  currently 

visible . 

This 

is 

done 

to  avoid 

having 

two  or  more 

occurrences 

of 

the 

same 

package  name  in  the  use  list. 

This  speeds 

up 

the 

search  process 

for  the 

symbol  table 

routines  since  they  only  have  to  search  a  package's  symbol 
table  once.  If  not  found  in  the  use_list  the  name  is 
added  to  the  use_list  and  processing  continues. 

5. 3. 2.1  CHANGES  TO  SYMBOL  TABLE  ROUTINES 

When  packages  are  added  to  the  subset  some  changes 
are  needed  in  the  symbol  table  routines.  The  first  change 
is  the  lookup  routine  must  be  changed  to  search  not  only 
the  current  symbol  table  but  also  the  symbol  tables  of  any 
visible  packages.  The  packages  that  are  visible  are  the 
ones  that  have  been  added  to  the  use_list.  A  consequence 
of  this  is  that  when  the  symbol  table  is  peeled  back  to  a 
previous  level  any  use  clauses  that  are  no  longer  visible 
must  be  removed  from  the  use_list. 

The  symbol  table  lookup  routine  must  also  be  able  to 
search  for  qualified  names  like  A.X  where  A  is  a  package 
name  and  X  is  a  name  declared  within  the  package.  This 
simply  means  the  with_list  must  be  searched  for  package  A 
and  the  the  symbol  table  for  package  A  is  searched  for  X. 

The  fields  of  the  two  structures  are  explained  well 

0 


8 


DESIGN  OF  THE  NEW  TOOLS 

enough  in  Appendix  E  so  no  discussion 
included  here. 
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6.  ULTIMATE  GOALS  AND  ENVIRONMENT 

The  ultimate  goal,  of  course,  is  to  get  a  full  Ada 
compiler  implemented.  This  should  be  done  with  certain 
other  goals  in  mind.  To  blindly  implement  the  full  Ada 
language  without  any  thought  to  the  remaining  development 
environment  would  be  foolish.  These  other  goals  concern 
the  environment  in  which  the  programmer  must  function. 


Each  of  these  goals  is 

aimed 

at  improving  programmer 

productivity 

and  reducing 

the 

time  spent 

testing  and 

fixing  a 

program.  These 

goals  are 

incremental 

compilation,  development  of  a  multitasked  environment,  and 
semantic  specif ication  of  the  language  in  use. 

6.1  INCREMENTAL  COMPILATION 

The  aim  of  incremental  compilation  is  to  further 
reduce  programmer  idle  time  during  the  development  cycle. 
This  is  accomplished  by  reducing  the  time  needed  to 
compile  a  program.  The  syntax  directed  editor  already 
does  some  of  this  by  maintaining  the  abstract  syntax  tree 
between  compiles.  This  eliminates  the  need  to  reparse  the 
program  each  time  it  is  compiled. 

Another  aspect  of  this  is  the  fact  that  the  source 
code  usually  changes  very  little  when  a  correction  or 
addition  to  it  is  made.  This  means  that  most  of  the  code 
the  compiler  generated  on  the  previous  run  is  still  valid 


% 
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and  could  be  reused  if  some  method  were  devised  to  tell 
the  compiler  which  nodes  had  changed. 

One  method  of  doing  this  is  to  have  the  syntax 
directed  editor  mark  each  node  in  the  abstract  syntax  tree 
with  a  flag  to  indicate  no  change,  a  change  in  this  node 
or  a  change  occurred  at  some  point  below  this  node.  Links 
between  the  generated  code  and  the  abstract  syntax  tree 
must  also  be  maintained  since  the  compiler  must  be  able  to 
change  the  code  if  necessary.  Since  the  compiler  would 
only  have  to  generate  code  for  those  parts  of  the  program 
which  had  changed,  significant  time  could  be  saved. 

Two  types  of  changes  can  cause  problems  for  an 
incremental  compiler.  The  first  is  any  change  in  the 
declaration  of  variables  or  subprograms.  Since  these 
changes  may  have  far  reaching  effects  even  on  sections  of 
the  program  which  have  not  changed  a  complete  recompile 
might  be  warranted.  This  is  especially  true  in  Ada 
because  of  the  problem  of  overloading  and  the  fact  that  no 
automatic  type  conversions  are  allowed. 

The  other  problem  is  more  specific  to  Ada.  It  is 
caused  when  the  environment  or  context  of  a  program  is 
changed  through  new  or  different  use  and  with  clauses. 
Once  again  a  total  recompile  might  be  warranted.  Since  a 
programmer  would  know  when  these  changes  had  been  made,  he 
could  control  the  compiler  through  a  pragma  to  turn  the 
incremental  feature  on  or  off. 
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6.2  MULTITASKED  ENVIRONMENT 

Multitasking,  which  Ada  supports,  is  another  means  of 
reducing  unproductive  time.  Since  the  CPU  tends  to  be 
relatively  idle  while  it  waits  further  user  inputs,  an 
incremental  compiler  and/or  a  semantic  analyzer  could  be 
run  as  separate  yet  parallel  tasks  to  the  editor.  The 
syntax  directed  editor  could  trigger  either  one  to  analyze 
a  section  of  code  that  the  user  had  just  entered  or 
changed.  A  specialized  interpreter/debugger  might  also  be 
written  to  allow  the  programmer  to  test  small  sections  of 
code  independent  of  the  rest  of  the  program. 

When  this  happens  the  tools  seem  to  merge  into  one 
multipurpose  tool  which  the  programmer  can  use  to  assist 
in  the  development  of  programs.  Using  this  tool  properly 
the  programmer  sees  faster  turnaround  and  a  program  that 
is  ready  to  test  almost  as  fast  as  it  can  be  entered  into 
the  system.  The  programmer  may  also  feel  more  confident 
that  the  program  is  correct  since  sections  of  the  code  can 
be  tested  as  they  are  written. 

The  multitasked  environment  does  present  some 
problems  to  be  solved.  These  are  mainly  in  the  interfaces 
between  the  tools  and  how  the  data  structures  in  use  are 
protected.  The  implementation  cannot  allow  two  or  more 
tools  to  work  on  the  same  limbs  of  the  tree  unless  the  two 
tools  are  compatible.  A  typical  example  that  must  be 
disallowed  is  having  the  editor  delete  a  subtree  while 
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another  tool  is  working  on  that  same  subtree. 


6.3  SEMANTIC  SPECIFICATION 

New  means  have  been  developed  to  extend  the  syntax 
description  of  a  language  to  include  its  semantic 
specification  (Ref  9,13).  These  extensions  could  be 
incorporated  in  a  way  that  would  allow  the  syntax  directed 
editor  to  use  the  semantic  information  to  prevent  semantic 
as  well  as  syntactic  errors.  This  is  no  trivial  task 
since  a  change  in  a  declaration  may  have  far  reaching 
effects.  To  be  used  by  a  programmer,  such  a  tool  must  not 
make  the  programmer  wait  after  such  a  change  has  been 


made . 

This 

probably  means  that  the  semantic 

checks 

would 

be  done 

in 

background 

and  errors  reported 

to  the 

user 

giving 

the 

user  the 

option  of  correcting 

the 

error 

immediately  or  continuing  with  the  current  effort  and 
returning  to  fix  the  errors  later. 
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7  RECOMMENDATIONS 

Extensions  to  this  thesis  effort  could  continue  in 
several  directions.  Several  major  extensions  were 
presented  in  the  previous  chapter.  Since  they  are  the 
ultimate  goals  of  this  effort,  any  extensions  should  be 
done  with  them  in  mind. 

Perhaps  the  most  important  continuation  would  be  the 
implementation  of  the  tools  designed  and  described  in 
Chapter  5.  The  extensions  that  were  designed  are  the 
semantic  analyzer,  the  data  structures  necessary  for  data 
types  and  packages,  and  a  method  to  allow  parameter 
passing  to  functions  and  procedures. 

7.1  ADA  SUBSET  EXPANSION 

The  moi  obvious  continuation  from  this  point  would 
be  to  continue  expanding  the  implemented  subset  until  a 
full  Ada  compiler  is  available.  This  would  be  not  only  a 
good  academic  exercise  but  would  also  be  useful  to  AFIT 
since  it  would  provide  the  school  with  a  new  tool  to  use. 
The  easiest  direction  to  take  in  this  effort  would 
probably  be  to  adapt  the  run  time  machine  developed  by 
Alan  Garlington  (Ref  11) .  Since  his  run  time  machine 
already  allows  tasking,  The  design  of  such  a  mechanism 
would  be  avoided. 
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7.2  REWRITE  TOOLS  INTO  ADA 

The  other  direction  to  take  with  this  effort  is  to 
quit  expanding  the  subset  and  to  rewrite  the  entire  system 
into  Ada.  This  becomes  especially  attractive  since 
several  Ada  compilers  have  been  validated  and  should 
become  available  for  use  soon.  Using  a  full  Ada  compiler 
avoids  the  problems  of  doing  the  rewrite  with  the  current 
subset . 

The  first  of  these  problems  is  speed.  Since  the 
current  implementation  compiles  to  an  intermediate  code 
that  is  interpreted  the  compilation  of  a  package  as  large 
as  the  current  support  environment  would  be  extremely  time 
consuming.  This  speed  problem  would  also  show  up  during 
execution  since  interpreting  code  is  much  slower  than 
running  the  equivalent  machine  code. 

The  other  drawback  is  memory  usage.  Currently  the 
abstract  syntax  tree  representation  of  a  program  takes 
about  eight  times  more  memory  than  the  equivalent  text 
representation.  Another  problem  is  the  symbol  table  and 
code  array  are  limited  due  to  the  way  they  are 
implemented.  This  could  be  solved  by  implementing  them  in 
a  more  dynamic  fashion  such  as  a  linked  list. 
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7.3  SUPPORT  ENVIRONMENT 

Other  directions  related  research  might  take  involve 
the  tools  in  the  support  environment.  Either  the  current 
tools  could  be  enhanced  or  new  tools  written.  Several 


useful 

new  tools  come  to 

mind. 

These 

include  a  code 

lister. 

a  code  optimizer. 

online 

help 

facility,  and  a 

program 

converter . 

7.3.1  CODE  LISTER 

The  code  lister,  as  currently  implemented,  is  a 
simple  tool  used  only  to  extract  the  code  generated  by  the 
compiler  and  print  it  for  the  programmer.  The  power  of 
the  code  lister  could  be  expanded  to  include  the  source 
lines  that  generated  the  code.  Since  the  code  is  already 
linked  to  the  abstract  syntax  tree,  the  source  code  is 
available  and  could  easily  be  included  in  the  listing. 
Shown  with  the  generated  code,  the  source  code  could  prove 
useful  in  showing  the  programmer  how  he  could  have  written 
a  fragment  of  code  more  efficiently.  Another  use  this 
could  have  is  as  a  debugging  aid.  The  programmer  could 
study  a  fragment  of  code  and  see  exactly  how  the  compiler 
interpreted  the  source  code.  This  might  help  him  spot  an 
error  that  was  caused  by  how  an  expression  is  evaluated. 


88 


RECOMMENDATIONS 


1 


7.3.2  CODE  OPTIMIZER 

A  code  optimizer  could  work  on  the  generated  code  to 
optimize  the  code  with  regard  to  some  characteristic  the 
programmer  wanted  to  improve.  This  characteristic  could 
be  execution  speed,  more  efficient  memory  usage,  or  any 
other  measure  the  programmer  desired.  The  optimized  code 
could  be  either  machine  language  code  or  code  for  the 
interpreter. 


7.3.3  ONLINE  HELP  TOOLS 

Online  help  tools  would  be  useful  for  training  or  as 
a  ready  reference  during  the  development  stage.  Several 
tools  come  to  mind.  The  first  is  a  tool  that  would  tell 
the  user  what  command  the  syntax  directed  editor  will 
accept  at  that  point  and  exactly  what  the  command  would 
do.  This  could  be  done  either  through  a  query  by  the  user 
or  intelligently  by  the  editor  as  it  realizes  the  user  is 
having  problems.  A  second  tool  would  allow  the  programmer 
to  check  what  constructs  the  syntax  would  currently  accept 
and  what  each  of  them  are. 

7.3.4  PROGRAM  CONVERTERS 

Program  converters  fall  into  two  basic  categories. 
The  first  would  be  a  tool  to  convert  a  program  written  in 
one  subset  of  Ada  into  an  expanded  subset.  This  would 
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probably  have  to  be  done  with  programmer  intervention 
where  a  choice  has  changed  or  a  newly  required  component 
is  needed  but  it  would  save  time  since  programs  would 
become  upwardly  compatible.  This  would  be  especially 
useful  if  the  support  environment  were  rewritten  into  the 
Ada  subset  before  a  full  Ada  compiler  is  available. 

Another  type  of  program  converter  would  translate  the 
abstract  syntax  tree  representation  into  some  other 
intermediate  form.  This  could  be  used  to  transfer 
programs  from  one  machine  to  another.  Since  the  Ada 
standard  has  proposed  a  new  language,  Diana,  be  used  for 
this  purpose,  it  could  serve  as  the  target  language.  This 
would  allow  programs  such  as  the  editor  to  be  more  easily 
transferred  from  one  computer  to  another. 

7.3.5  INTERPRETER 

The  current  interpreter  could  be  improved  to  run 
faster,  use  less  memory  or  a  combination  of  the  two.  It 
could  also  be  changed  to  do  dynamic  type  and  range 
checking.  Since  tasking  is  a  feature  of  Ada,  a  tasking 
interpreter  could  be  written  either  from  Garlington's 
design  (Ref  11)  or  a  design  of  the  user's  choosing. 
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7.3.6  PROGRAM  LISTER 

The  program  lister  could  be  improved  to  give  the 
programmer  a  more  detailed  listing  of  the  program.  One 
such  improvement  could  be  the  generation  of  a  cross 
reference  listing  for  the  program. 

7.3.7  DEBUGGING  TOOLS 

The  debugging  tools  could  be  improved  to  do  more  run 
time  checks  and  some  execution  analysis.  The  execution 
analysis  could  include  listing  how  many  times  a  statement 
was  executed,  detecting  that  a  variable  is  used  before  it 
is  initialized,  or  detecting  that  certain  fragments  of 
code  are  unreachable  and  are  therefore  can  be  eliminated. 
Another  debugging  tool  that  could  be  written  is  a  tool  to 
automatically  generate  test  data  based  on  an  analysis  of 
the  program  being  tested. 
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APPENDIX  A.  META  DESCRIPTION  FOR  THE  ADA1  SUBSET 


The  following  is  the  META  description  of  the  ADA1 
subset  implemented  by  the  ADA1  compiler. 


compilation  = 

compilation_unit  ; 

compilation_unit  =  < 
func_body 
proc_body  > ; 

func_body  = 

[  program_header  ] 

@  func_spec  ~  "is" 

[  +  decl  1 

{  +  program_component  } 

@  "begin" 

+  seq_of_stmts 

@  "end"  [  ~  designator  ]  ";"  ; 
func_spec  * 

j  "function"  ~  designator  *  "return" 

,  *  subtype_indication  ; 

r 

j  designator  =  < 

‘  identifier  >; 


proc_body  = 

f  program_header  ] 

@  proc_spec  “  "is" 

C  +  decl  } 

{  +  program  component  } 
@  "begin" 

+  seq_of_stmts 

@  "end"  [  ~  identifier  ]  ";"  ; 

program_header  = 
comment 

(  @  comment  J  ; 
proc_spec  = 

"procedure"  *  identifier  ; 

decl  * 

object  decl  [  ‘  comment  ]  ; 
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program_component  =  < 
func_body 
proc_body  >; 

seq_of_stmts  = 
stmt 

[  @  stmt  )  ; 
identifier  = 

' AZ | az ’  C  ' 09 | AZ |_[ az '  ]  ; 
object_decl  = 

id_Iist  “  ~  "constant”  ]  ~  object_type 

[  ~  initial  ]  ; 


stmt  = 

simple_stmt  [  *  comment  ]  ; 
id_list  = 

identifier  C  identifiers  }  ; 

object_type  =  < 

subtype  indication  >; 


initial  * 

*  expression  ; 


simple_stmt  =  < 

assignment_stmt 

if_stmt 

loop_stmt 

return_st:mt 

proc_call 

comment 

null_stmt  >; 

identifiers  = 

“  identifier  ; 

subtype_indication  =  < 
"integer" 

"boolean" 

"char"  > ; 

expression  =  < 

relation 

and_comp 

or_comp 

and_then_comp 

or_else_comp 

xor_comp  >; 


95 


T 


APPENDIX  A 


assignment_stmt  = 

name  ~  ~  expression  ; 

if_stmt  = 

"if"  ~  expression  *  "then" 

+  seq_of_stmts 
C  @  elsif_part  } 

{  @  else_part  ] 

@  "end"  ~  "if"  ";H  ; 

loop_stmt  = 

t  iteration_clause  *  ]  "loop" 

+  seq_of_stmts 
@  "end"  *  "loop"  " ? "  ; 

proc_call  = 

name  " ; "  ; 

return_stmt  =  < 

procedure_return 
function_return  >  ; 

comment  = 

»—  •'  c  *  3  ’  3  ? 


null  stmt  = 

"null;"  ; 

procedure_return  = 

"return;"  ; 

function  return  = 

’’’return"  **  expression  ";"  ; 

name  =  < 

identifier  >;r 
relation  = 

simple_exp  [  “  relation_part  !  ] 
and_comp  = 

relation  l  ~  and_relation  }  ; 
or_comp  = 

relation  (  ~  or_relation  }  ; 
and_then_comp  = 

relation  (  ~  and_then_relation  ] 
or_else_comp  * 

relation  (  ~  or  else  relation  3 
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xor_comp  * 

relation  C  *  xor_relation  }  ; 
elsif_part  = 

"elsif"  ~  expression  *  "then" 
+  seq_of_stmts  ? 

else  part  = 

"else" 

+  seq_of_stmts  ; 

iteration_clause  =  < 

while_clause  >; 

simple_exp  = 

[  unary_operator  I  ]  term  ( 

relation_part  =  < 

relational  >; 

and_relation  = 

"and"  *  relation  ; 

or_relation  = 

"or"  *  relation  ; 

and_then_relation  = 

"and  then"  ~  relation  ; 

or_else_relation  = 

"or  else"  ~  relation  ; 

xor_relation  = 

"xor"  “*  relation  ; 

while_clause  « 

"while" 

unary_operator 

I*  w 

> ; 

term  » 

factor  (  "  factors  }  ; 

terms  * 

add_op  “  term  ; 

relational  » 

rel  op  “  simple_exp  ; 


~  expression  ; 
< 


terms  }  ; 
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factor  =  < 

e*P_primary 
abs_primary 
not_primary  >; 


factors  = 

mul_op  *  factor  ; 

exp_primary  = 

primary  [  *  expon_part  !  }  ; 

expon_part  = 

"**"  -  primary  ; 


abs_primary  = 

"abs"  ~  primary  ; 

not_primary  = 

"not"  *  primary  ,* 

add_op  =  < 

»•  .  »» 


rel_op  =  < 

••  _  »» 

»f  j  _  II 

»•  ^  »» 

W  <  =  W 
l»  y  II 

">="  > ; 

primary  =  < 

decimal_number 

name 

nested_exp 
char_lit 
boolean_value 
func_call  > ; 

func_call  * 

designator  "("  ")"  ; 

mul  op  =  < 

»*  » 
ft  j  It 

"mod" 

"rem"  >; 

decimal_number  = 
integer  ; 
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nested_exp  = 

"("  expression 

integer  = 

'09'  C  ' 0  9 { _ *  3 

char_lit  = 

It  I  II  l  ->1  II  l  M  . 


boolean_value  =  < 
"true" 
"false"  > ; 
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APPENDIX  B.  OUTPUT  OF  THE  META  PROGRAM 


The  following  is  the  output  produced  by  META  when  the 
ADA1  grammar  was  used  as  input. 


META  10/15/82 


Source  input  =  adalx.syn. 
Output  file  =  adalx.sdf. 
Goal  symbol:  compilation. 


item  name . 

alt/cat . . 

term/non . . 

3 

1 

2 

set 

2 

terminal 

( 

) 

2 

terminal 

2 

terminal 

★ 

1 

terminal 

*  ★ 

1 

terminal 

2 

terminal 

1 

terminal 

2 

terminal 

_  _ 

1 

terminal 

/ 

1 

terminal 

/  = 

1 

terminal 

09 

1 

set 

09  AZ |  | az 

1 

set 

09 

1 

set 

. 

1 

terminal 

•  — 

2 

terminal 

• 

8 

terminal 

< 

1 

terminal 

<  = 

1 

terminal 

1 

terminal 

> 

1 

terminal 

>  = 

1 

terminal 

AZ  |  az 

1 

set 

abs 

1 

terminal 

abs  primary 

1 

non-term 

cat 

add  op 

1 

non-term 

alt 

and 

1 

terminal 

and  then 

1 

terminal 

and  comp 

1 

non-term 

cat 

and_relation 

1 

non-term 

cat 
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and  then  comp 

1 

non-term 

cat 

and  then  relation 

1 

non-term 

cat 

assignment_stmt 

1 

non-term 

cat 

begin 

2 

terminal 

boolean 

1 

terminal 

boolean_value 

1 

non-term 

alt 

char 

1 

terminal 

char_lit 

1 

non-term 

cat 

comment 

5 

non-term 

cat 

compilation 

1 

non-term 

cat 

a  single 

unconditional 

term. 

compi lation_unit 

1 

non-term 

alt 

constant 

1 

terminal 

decimal_number 

1 

non-term 

cat 

a  single 

unconditional 

term. 

decl 

2 

non-term 

cat 

designator 

3 

non-term 

alt 

a  single 

alternative. 

else 

1 

terminal 

else_part 

1 

non-term 

cat 

elsif 

1 

terminal 

elsif_part 

1 

non-term 

cat 

end 

4 

terminal 

exp_primary 

1 

non-term 

cat 

expon_part 

1 

non-term 

cat 

expression 

7 

non-term 

alt 

factor 

2 

non-term 

alt 

factors 

1 

non-term 

cat 

false 

1 

terminal 

func_body 

2 

non-term 

cat 

func_cal 1 

1 

non-term 

cat 

func_spec 

1 

non-term 

cat 

function 

1 

terminal 

function_return 

1 

non-term 

cat 

id_list 

1 

non-term 

cat 

identifier 

6 

non-term 

cat 

identifiers 

1 

non-term 

cat 

if 

2 

terminal 

if_stmt 

1 

non-term 

cat 

initial 

1 

non-term 

cat 

integer 

1 

terminal 

integer 

1 

non-term 

cat 

is 

2 

terminal 

iteratioh_clause 

1 

non-term 

alt 

a  single 

alternative . 

loop 

2 

terminal 

loop_stmt 

1 

non-term 

cat 
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mod 

1 

terminal 

mul_op 

1 

non-term 

alt 

name 

3 

non-term 

alt 

a  single  alternative. 

nested_exp 

1 

non-term 

cat 

not 

1 

terminal 

not_primary 

1 

non-term 

cat 

null; 

1 

terminal 

null_stmt 

1 

non-term 

cat 

a  single  unconditional 
ob ject_decl 

term. 

1 

non-term 

cat 

object_type 

1 

non-term 

alt 

alternation  alternative 

:  subtype 

indication. 

a  single  alternative. 

or 

1 

terminal 

or  else 

1 

terminal 

or_comp 

1 

non-term 

cat 

or_else_comp 

1 

non-term 

cat 

or_e 1 se_re 1 at ion 

1 

non-term 

cat 

or_relation 

1 

non-term 

cat 

primary 

4 

non-term 

alt 

alternation  alternative 
alternation  alternative 

:  name . 

;  boolean 

_value . 

proc  body 

2 

non-term 

cat 

proc_call 

1 

non-term 

cat 

proc_spec 

1 

non-term 

cat 

procedure 

1 

terminal 

procedure_return 

1 

non-term 

cat 

a  single  unconditional 
program__component 

term. 

2 

non-term 

alt 

program_header 

2 

non-term 

cat 

rel_op 

1 

non-term 

alt 

relation 

11 

non-term 

cat 

relation  part 

1 

non-term 

alt 

a  single  alternative. 

relational 

1 

non-term 

cat 

rem 

1 

terminal 

return 

2 

terminal 

return; 

1 

terminal 

return_stmt 

1 

non-term 

alt 

seq_of_stmts 

6 

non-term 

cat 

simple_exp 

2 

non-term 

cat 

simple_stmt 

1 

non-term 

alt 

alternation  alternative 

:  return 

stmt. 

stmt 

2 

non-term 

cat 

subtype_indication 

2 

non-term 

alt 

term 

2 

non-term 

cat 

terms 

1 

non-term 

cat 

then 

2 

terminal 

true 

1 

terminal 

unary_operator 

1 

non-term 

alt 

while 

1 

terminal 
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while_clause  1 

xor  1 

xor_comp  1 

xor_reiation  1 

121  elements  described. 

312  nodes  in  syntax  description  file. 

0  errors  detected. 

META  processing  complete. 


non-term  cat 
terminal 
non-term  cat 
non-term  cat 
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APPENDIX  C.  DESIGN  FOR  PASSING  PARAMETERS  TO  SUBPROGRAMS 


1.  Find  the  subprogram  name  in  the  symbol  table. 

2.  Get  the  next  parameter  from  the  associated  parameter 
list. 

3.  Determine  the  type  parameter  it  is.  If  it  is  an  in 
parameter  goto  step  4.  if  it  is  an  out  or  an  in  out 
parameter  goto  step  5. 

4.  Call  expression  to  evaluate  the  parameter.  A  type 
will  be  returned  verify  the  type  is  correct. 

Generate  an  instruction  to  pop  the  stack.  This  last 
instruction  is  put  into  a  list  so  that  it  can  be 
appended  to  the  code  array  after  all  parameters  are 
evaluated.  Goto  step  . 

5.  Verify  the  actual  parameter  is  a  variable  name  that 
has  a  location  associated  with  it.  If  not  generate 
an  error  that  says  the  parameter  must  be  a  name  and 
not  an  expression. 

6.  Check  if  the  actual  parameter  is  an  indexed 
component.  If  it  is  then  goto  step  9. 

7.  If  the  formal  parameter  is  an  out  parameter  generate 
an  instruction  to  load  the  undefined  value.  If  it  is 
an  in  out  parameter  generate  the  code  to  load  the 
value. 

8.  Generate  an  instruction  to  store  the  value  back  and 
prepend  this  instruction  to  the  list  of  instructions 
that  will  be  added  to  the  code  array  after  all 
parameters  are  processed.  Goto  step  . 

9.  Generate  code  to  evaluate  the  index.  If  the 
parameter  is  an  out  parameter  goto  step  10.  If  it  is 
an  in  out  parameter  generate  an  instruction  to  copy 
the  index  to  the  index  stack.  This  instruction  will 
leave  the  index  on  the  run  time  stack.  Generate  an 
instruction  to  load  the  value  onto  the  stack  using 
the  index  on  top  of  stack.  Goto  step  11. 

10.  Generate  an  instruction  to  move  the  index  from  the 

run  time  stack  to  the  index  stack.  This  instruction 
removes  the  index  from  the  run  time  stack.  Generate 
an  instruction  to  load  the  undefined  value  onto  the 
run  time  stack. 
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11.  Generate  an  instruction  to  save  the  value  when  the 
procedure  returns.  Prepend  this  instruction  to  the 
list  of  instructions  to  be  added  to  the  code  array 
after  all  parameters  are  evaluated. 

12.  Check  if  another  parameter  is  needed  for  this 
procedure.  Check  if  a  parameter  is  available.  If 
both  are  true  goto  step  2.  If  not  generate  an  error 
saying  either  a  parameter  is  missing  or  an  extra 
parameter  was  passed. 

13.  Append  the  list  of  instructions  beings  held  at  bay  to 
the  code  array. 

14.  Return  control  up  the  tree. 
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APPENDIX  D.  A  DESIGN  FOR  THE  SEMANTIC  ANALYZER 


1.  If  the  expression  is  a  function  call  goto  step  34. 

2.  If  the  expression  is  a  procedure  call  goto  step  23. 

3.  If  the  expression  is  a  name  goto  step  step  19. 

4.  (Expression  still  has  an  operator)  Find  the 

controlling  operator.  It  is  the  rightmost  operator  at 
this  level  in  the  tree. 

5.  If  the  operator  is  a  unary  operator  goto  step  18 

6.  (Binary  operator)  Find  all  occurrences  of  the  operator 
in  the  symbol  table.  If  none  return  error. 

7.  Create  an  operator  list  entry  for  each  occurrence. 

8.  If  a  type  list  was  passed  in  eliminate  any  entries  in 
the  operator  list  that  cannot  return  one  of  the  desired 
types . 

9.  If  the  operator  list  is  empty  return  error. 

10.  Create  the  left  operand  list  from  the  operator  list. 

11.  Call  the  semantic  analyzer  with  the  left  operand  list 
and  the  left  hand  operand. 

12.  If  error  is  returned  return  error. 

13.  Compare  the  returned  type  list  with  the  operator  list. 
Eliminate  elements  from  operator  list  whose  left  hand 
operand  type  does  not  appear  in  the  returned  type  list. 

14.  Repeat  steps  9-13  for  right  hand  operator. 

15.  If  the  list  is  empty  return  error. 

16.  If  the  operator  contains  a  single  entry  goto  step  call 
pass3.  If  pass3  returns  error  return  error. 

17.  Create  operand  list  from  the  return  types  of  the 
operator  list.  Return  this  list. 

18.  (Unary  operator)  Same  as  a  binary  operator  (steps 
6-17)  except  only  done  for  a  single  right  hand 
operator. 

19.  (Name)  Find  all  occurrences  of  the  name  in  the  symbol 
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table.  If  none  return  error. 

20.  Create  an  operand  list  element  for  each  entry. 

21.  If  a  type  list  was  passed  in  eliminate  the  unavailable 
types  from  it  by  comparing  it  to  the  operand  list 
created  in  step  20.  Return  the  modified  type  list. 

22.  No  list  passed  in  return  the  operand  list  generated  in 
step  20. 

23.  (Procedure  call)  Find  all  occurrences  of  the  procedure 
name  in  the  symbol  table.  If  none  return  error. 

24.  Count  the  number  of  actual  parameters  used  in  the 
procedure  call. 

25.  Create  a  list  of  the  procedures  found  in  the  symbol 
table  which  need  that  number  of  parameters.  If  the 
list  is  empty  return  error. 

26.  If  no  parameters  are  needed  and  more  than  one  procedure 
is  possible  return  error.  Else  mark  the  syntax  tree 
node  with  the  symbol  table  entry  of  the  procedure  name 
and  return  success. 

27.  Repeat  steps  28-32  for  each  parameter  and  procedure  in 
turn. 

28.  Check  if  the  first  actual  parameter  is  a  name  or  an 
expression.  If  it  is  an  expression  eliminate  all 
procedures  that  require  an  out  or  in  out  parameter.  If 
the  list  is  now  empty  return  error. 

29.  Create  an  operand  list  from  the  procedure  list  for  this 
parameter. 

30.  Call  the  semantic  analyzer  with  the  operand  list  and 
the  first  parameter. 

31.  If  error  is  returned  return  error. 

32.  Compare  the  returned  type  list  with  the  procedure  list 
and  eliminate  any  procedures  which  do  not  have  this 
parameter  available. 
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33.  If  two  or  more  procedures  remain  in  the  procedure  list 
return  error.  If  only  one  remains  call  pass  3  with 
each  parameter  and  its  type  in  turn.  Return  success. 

34.  (Function  call)  Same  as  procedure  except  as  noted 
below. 

35.  Add  step  25a.  If  a  type  list  is  passed  in  compare  it 
to  the  types  that  can  be  returned.  Eliminate  any 
functions  which  cannot  return  a  valid  type. 

36.  Eliminate  step  28  since  only  in  parameters  are  allowed. 

37.  Change  step  33  to  If  two  or  more  functions  remain  in 
the  list  create  the  type  list  from  their  return  types 
and  return  the  list.  If  a  single  function  is  in  the 
list  call  pass  3  with  each  parameter  and  its  type  in 
turn.  If  pass  3  returns  error  return  error.  Otherwise 
return  the  type  of  the  function. 


PASS  3 

Pass  3  is  very  similar  to  the  actual  semantic  analyzer 
except  that  no  multiple  types  are  allowed  to  be  returned. 
If  at  any  time  during  this  pass  an  ambiguity  cannot  be 
resolved  the  expression  is  in  error  and  error  is  returned. 
As  each  node  of  the  syntax  tree  is  correctly  typed  it  is 
marked  with  the  appropriate  symbol  table  pointer  and  a  flag 
is  raised  to  indicate  the  expression  is  ok  below  this  node. 
Pass  3  must  check  this  flag  before  it  descends  the  tree 
further.  This  is  only  to  avoid  resolving  ambiguities  more 
than  one  time. 
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APPENDIX  E  -  SYSTEMS  USERS  MANUAL 

This  appendix  describes  how  the  compiler, 
interpreter,  and  code  lister  are  invoked,  the  inputs  they 
expect  and  the  outputs  they  produce. 

Before  any  of  these  tools  can  be  used  a  program  must 
be  entered  using  the  syntax  directed  editor.  The  syntax 
directed  editor  is  invoked  with  the  command,  synde  TEST 
adalx.  This  command  will  produce  a  program  file  named 
TEST  using  the  language  ADA1X .  For  more  information  on 
using  the  syntax  directed  editor  refer  to  the  syntax 
directed  editor  users  manual  (Ref  9) . 

E.l  INVOKING  THE  COMPILER 

The  compiler  can  be  invoked  in  three  ways,  from  the 
syntax  directed  editor,  directly  by  the  user,  or  by  the 
interpreter. 


E.1.1  FROM  THE  SYNTAX  DIRECTED  EDITOR 

To  invoke  the  compiler  from  the  syntax  directed 
editor  simply  enter  the  invoke  compiler  command.  This 
command  is  selected  by  the  user  when  the  editor  is 
configured  using  the  CONFIG  program  (Ref  9) .  The  compiler 
can  be  used  in  this  way  to  do  a  preliminary  semantic  check 
of  the  program. 
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The  compiler  will  flag  up  to  five  errors  using 
program  tree  markers.  The  compiler  will  halt  processing 
when  either  all  error  markers  are  used  or  the  compilation 
is  complete.  If  invoked  in  this  manner  the  compiler  will 
return  control  to  the  syntax  directed  editor  with  the 
focus  set  at  the  first  error  in  the  program  or  at  the  root 
of  the  program  tree  if  no  errors  were  detected.  The  user 
can  then  correct  any  errors  and  continue  entering  the 
program. 

£.1.2  DIRECTLY  BY  THE  USER 

The  second  way  to  invoke  the  compiler  is  with  the 
command  adalxC  TEST,  where  TEST  is  the  program  the  user 
wants  to  compile.  The  compiler  will  still  flag  up  to  five 
errors  and  will  return  control  to  the  command  level  when 
five  errors  are  found  or  compilation  is  completed.  To  fix 
an  error  the  user  need  only  invoke  the  editor  with  the 
command,  synde  TEST.  The  editor  will  put  the  focus  at  the 
first  error  or  at  the  root  of  the  tree  if  no  errors  were 
detected. 

E.1.3  FROM  THE  INTERPRETER 

The  third  way  to  invoke  the  compiler  is  through  the 
interpreter.  The  interpreter  calls  the  compiler  to 
generate  the  code  it  is  to  interpret  and  to  link  that  code 
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to  the  abstract  syntax  representation  of  the  program.  The 
interpreter  is  invoked  as  shown  below. 


E.1.4  COMPILER  INPUTS  AND  OUTPUTS 

The  compiler  expects  no  special  inputs  other  than  the 
program  file  given  on  the  command  line.  The  compiler 
produces  a  file  called  TEST. cod  where  TEST  is  the  name  of 
the  input  program  file. 

E.2  INVOKING  THE  INTERPRETER 

The  interpreter  can  be  invoked  in  two  ways ,  from  the 
syntax  directed  editor,  or  directly  by  the  user. 

E.2.1  FROM  THE  SYNTAX  DIRECTED  EDITOR 

To  invoke  the  interpreter  from  the  syntax  directed 
editor  simply  enter  the  invoke  interpreter  command.  This 
command  is  selected  by  the  user  when  the  editor  is 
configured  for  the  terminal  in  use  (Ref  9) .  The 

interpreter  can  be  used  in  this  way  to  do  a  preliminary 
semantic  and  logic  check  of  the  program.  This  can  be 
especially  useful  if  the  user  is  not  certain  what  a 

specific  instruction  will  do. 

The  interpreter  first  calls  the  compiler  to  compile 
the  program.  The  compiler  works  as  described  above.  When 
control  is  returned  to  the  interpreter,  it  checks  if  any 
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errors  were  detected.  If  some  were  the  interpreter  asks 
the  user  if  execution  is  to  continue.  If  not  control  is 
returned  to  the  syntax  directed  editor  as  described  above 
with  the  focus  at  the  first  error.  If  execution  is 
allowed  or  the  program  had  no  errors,  the  execution 
routine  is  called.  Operation  of  the  execution  routine  is 
explained  below. 


E.2.2  DIRECTLY  BY  THE  USER 

The  other  way  to  invoke  the  interpreter  is  with  the 
command  adalxl  TEST.  This  will  cause  the  interpreter  to 
compile  and  execute  the  program  TEST.  The  interpreter 
functions  as  explained  above  except  that  control  will  be 
returned  to  the  command  level  rather  than  to  the  syntax 
directed  editor. 

E. 3  PROGRAM  EXECUTION 

When  a  program  is  executed  control  is  returned  to  the 
user.  The  user  is  given  a  display  showing  the  program, 
the  top  few  elements  of  the  program  stack,  and  the  next 
instruction  to  be  executed.  The  portion  of  the  program 
thought  responsible  for  that  instruction  is  highlighted  in 
reverse  video.  The  user  is  also  given  a  choice  of  four 
commands  to  input.  The  four  commands  are  single  step, 
continue  execution,  restart,  and  exit. 
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Any  command  not  described  below  is  ignored  and  the 
user  is  prompted  to  enter  a  new  command. 

E.3.1  SINGLE  STEP 

The  single  step  command,  invoked  by  'S’  or  '  ' , 
causes  execution  of  the  displayed  instruction.  The 
display  is  updated  and  the  user  is  shown  the  new  program 
stack,  the  next  instruction,  and  the  next  program  fragment 
is  highlighted.  If  the  instruction  executed  was  the  last 
instruction  of  the  program  or  an  INVALID  instruction,  the 
interpreter  is  reset  to  reexecute  the  program  from  the 
beginning,  and  the  display  is  reset  to  its  initial  state. 

E.3.2  CONTINUE  EXECUTION 

The  continue  execution  command,  invoked  by  ' C', 
causes  the  interpreter  to  execute  the  program  in  a 
continuous  fashion  until  the  end  of  program  is  found.  The 
displays  are  updated  as  if  the  user  was  single  stepping 
the  program  very  rapidly.  When  the  end  of  the  program  is 
found  the  interpreter  is  reset  as  before  and  the  user  is 
prompted  for  further  inputs. 

E.3.3  RESTART 

The  restart  command,  invoked  by  'R',  causes  the 
interpreter  to  reset  itself  to  its  initial  state.  Program 
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execution  will  continue  at  the  start  of  the  program. 


E.3.4  EXIT 

The  exit  command,  invoked  by  'E',  causes  the 
interpreter  to  halt  execution  and  return  control  either  to 
the  syntax  directed  editor  or  to  the  command  level 
depending  on  how  the  interpreter  was  invoked. 

E.3.5  INTERPRETER  INPUTS  AND  OUTPUTS 

The  interpreter  expects  only  those  inputs  described 
above.  Any  other  inputs  are  ignored.  The  interpreter 
produces  no  outputs  of  its  own  other  than  the  displays 
described  above.  The  compiler  does  produce  the  file 
TEST. cod  where  TEST  is  the  input  program  file  name. 


E . 4  THE  CODE  LISTER 

The  code  lister  is  invoked  by  the  command,  codelist 
TEST,  where  TEST  is  the  name  of  the  program  whose  code  the 
user  wants  to  list.  The  file  TEST. cod  must  exist.  This 
is  the  file  produced  by  the  compiler  when  the  program  is 
compiled.  The  code  lister  produces  an  output  file  called 
TEST.codlst.  This  file  can  then  be  read  and  displayed  by 
any  program  which  uses  a  standard  text  file  as  input  such 
as  cat,  more,  vpr. 
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*  SYNtax-Directed  Editor  (c)  Copyright  December  1982 

«  CAPT.  Scott  Eduard  Ferguson,  USAF,  AFIT  SCS-82D 

*  Modified  October  1983 

«  CAPT.  Michael  l.  HcCracken,  USAF,  AFIT  6CS-83D 

*  SYNOE.H 

*  Define  global  inforeation  types  and  values  for  SYNDE  data 

*  structures. 

HHMHHHHiHMIHHHHItitHHIHtHiitlWtHHIHHIlHIHI 


(include  <stdio.h> 


•include  ’ctype.h* 


•define  SUCCESS  1 

/•  success  return  value 

*/ 

•define  ERROR  (-1) 

/ *  error  return  value 

t/ 

/*  special  defined  types 

*/ 

•define  RE6  register  int 

/*  type  for  register  optioization 

♦/ 

•define  BOOL  int 

/*  type  declaration  for  boolean  values 

*/ 

•define  TRUE  1 

/•  boolean  TRUE  constant 

»/ 

•define  FALSE  0 

/«  boolean  FALSE  constant 

t  / 

/»  file  action  status  "enuseration"  values 

#/ 

•define  T0.LIST  1 

/•  vector  execution  to  lister 

*/ 

•define  TO  C0HP  2 

/*  vector  execution  to  coapiler 

*/ 

•define  T0.INT  3 

/«  vector  execution  to  interpreter 

*/ 

•define  T0.SYN  4 

/»  vector  execution  to  synde 

*/ 
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/IHWHHHHMHIHIHMMMIHHHHMIHMIHHHHHHIHMHHHHI 

a  Abstract  Syntax  Trot  (AST)  node  description.  * 


ttruct  ast.node  ( 

/•  AST  node  structure 

a/ 

char 

a.fl«4*« 

/a  AST  node  flags  (described  below) 

a/ 

a.valuel 

/•  contains  character  (or  0)  for  a  node  •/ 

/a  cxresponding  to  a  'set*  eleoent*/ 

unsiqned 

a  / 

».pTOd, 

/a  'pointer*  to  syntax  eleoent 

/a  corresponding  to  this  node 

a/ 

a.right, 

/a  'pointer'  to  right  sibling!  if  RTHOBTa/ 

/a  is  set,  this  points  to  father 

a/ 

a_ton( 

/a  'pointer*  to  node's  leftoost  son  x 

a/ 

M 

/a  NIL  if  node  is  a  leaf  node 

a/ 

•define  NIL 

0 

/•  NIL  pointer  to  'no*  AST  node 

a/ 

/a  a.flags  aaiks  for  bit-fiald  valun 

a/ 

•dofino  RTN08T 

0x01 

/a  node  is  rightaost  son 

a/ 

Idcfint  LTNOST 

0x02 

/a  node  is  leftoost  son 

a/ 

•dofino  ONLY 

0x03 

/a  node  is  only  child  (left  and  right) 

a/ 

•define  ROOT 

0x04 

/•  node  is  an  AST  tree  root 

a/ 

•define  OPEN 

0x10 

/•  node  is  an  unsatisfied  conditional 

a/ 

•define  ELIDE 

0x20 

1*  nark  to  suppress  display  of  subtree 

a/ 

•define  NARK 

0x40 

/•  node  is  Barked  in  f.nark  list 

a/ 

•define  FREE 

Ox  BO 

/•  node  is  free  (unallocated) 

a/ 
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•  Syntax  Trii  nodi  diicription.  « 

HHHHHHHHHHWHtHHHHHUUHtWHHHHHIHHHHHIHH/ 

struct  syn.nodi  ( 
unslgnid 

s.fligii  /•  nodi  flags  (discribid  below)  1/ 

s.linki  /*  if  hudir:  1/ 

/•  "pointir*  to  nai  string!/ 


/!  if  llHMt: 

4/ 

>! 

/»  'pointir*  to  hiadir 

4/ 

Idifini  HAI.ALT  20 

/•  sax  nuobir  of  altirnativn 

4/ 

/«  in  an  alternation 

4/ 

/*  s.flags  inks  for  bit-fiild  viluis 

4/ 

/•  for  a  definition  hudir  nodi — ■ 

4/ 

Idifini  ALT 

0x0001 

/«  altirnation  rule  hiadir 

4/ 

Mifini  CAT 

0x0002 

/*  concatenation  rule  hiadir 

4/ 

Idifini  RULE 

0x0003 

/»  ruli  header 

4/ 

Mifini  STR 

0x0004 

1*  string  hiadir 

4/ 

Mifini  SET 

0x0008 

/i  sit  hiadir 

4/ 

Mifini  HEAD 

OxOOOF 

/t  nodi  is  a  hiadir  nodi 

4/ 

/!  for  a  ruli  ilnmt  nodi*— 

4/ 

Mifini  OPTION 

0x0010 

/*  optional  ruli  ilnmt 

4/ 

Mifini  REPEAT 

0x0020 

/•  ripiatid  ruli  ilnmt 

4/ 

Mifini  CONS 

0x0030 

/i  conditional  OPTION  or  REPEAT  #/ 

Mifini  HIDE 

0x0040 

/»  hiddm  conditional 

4/ 

/*  output  foroats: 

4/ 

Mifini  HEMLINE 

0x0100 

/*  nmlini 

4/ 

Mifini  INDENT 

0x0200 

/!  indmt  (and  nmlini) 

4/ 

Mifini  LINE 

0x0300 

/*  gmiratn  nn  lim 

4/ 

Mifini  PRESP 

0x0400 

/*  spaci  prtcidit  nodi 

4/ 

Mifini  POSTSP 

0x0800 

/«  spaci  follows  nodi 

4/ 

/KHIHKHHIHHHMWIlHHHWtUHHHHHmtHtWMmmimH 

•  Iiagi  Bmiration  paraaittri. 

4 

HHttHHHHHHHWWIHIimHHiHHIHHHIHHIHUHHHHHH/ 

Idifini  HIDE  132  /•  us  scrnn  width  in  cbsrictirs  *1 

Mifini  DEE?  30  /•  in  scrim  diptb  in  linn  •/ 

Idifini  HILITE  0x80  /»  highlight  bit  for  display  */ 
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/ ************************************************************************ 
*  Source  File  indorsation  block.  * 

************************************************************************1 


struct  file.info  ! 

int 

f.bufl 

char 

f  naan! 161, 

/♦  croation  lilt  nas* 

*1 

Mangll61, 

/»  associated  language  granner  naac 

*! 

4  croatl 161, 

1*  croation  data 

*1 

Mast!  161, 

/»  last  access  data 

*/ 

f.conf!34]j 

/*  configuration  control  intonation 

*1 

int 

f.edit, 

/•  return  control  to  SYRDE  editor 

*/ 

f.update, 

/•  version  update  count 

»/ 

I. avail, 

/*  'pointer*  to  available  list  head 

*/ 

f_root. 

/•  'pointer*  to  prograa  tree  root 

»/ 

Mlip, 

/•  'pointer*  to  dipping  tree  root 

*1 

f.narkllOU 

/*  place  urkers,  S  thru  9  reserved  as 

*1 

/•  error  aarkers 

*1 

>1 


t  Tereinal  Description  Flit  characteristics  block.  * 

****************************H**************************************** »*l 


I*  input  coaaand  'MUMrition*  values  */ 


•define  .RIGHT 

1 

/•  nova  right 

•/ 

•define  .LEFT 

2 

/*  nova  left 

»/ 

•define  .LEAF 

3 

/<  nova  to  leaf  node 

•/ 

•define  .LAST 

4 

/•  save  back  to  last  focus 

»/ 

•define  .UP 

S 

/•  save  up 

t/ 

•define  DOW 

6 

/•  save  doun 

*/ 

•define  .LUP 

7 

/*  long  up  (skip  only  child  nodes) 

•/ 

•define  LDOW 

8 

/•  long  doun  (skip  only  child  nodes) 

*1 

•define  .RIN8 

9 

/*  insert  conditional  right 

* 1 

•define  L1N8 

10 

/•  insert  conditional  left 

»/ 

•define  .CLIP 

11 

/•  clip  subtree 

»/ 

•define  .DEL 

12 

/•  delete  subtree  (clip  and  kill) 

*1 

•define  .KILL 

13 

/•  kill  subtree 

♦/ 

•define  COPY 

14 

/•  copy  subtree 

•/ 

•define  .ELIDE 

13 

/•  elide  subtree  (suppress  display) 

*1 

•define  .HELP 

16 

/•  help 

•/ 

•define  .NINDQN 

17 

/*  open/close  second  uindoo 

•/ 

•define  SEARCH 

18 

/•  search  to  literal  string 

•/ 

•define  .AGAIN 

19 

/i  search  again 

»/ 

•define  .NARK 

20 

/«  set/clear  node  darker 

*/ 

•define  .80 

21 

/•  go  to  node  eerker 

*/ 

•define  CONP 

22 

/•  invoke  coepiler 

•/ 

•define  .INT 

23 

/•  invoke  interpreter 

*/ 

•define  LIST 

24 

/•  invoke  lister 

t  / 
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idtfint  JYNOE 

23 

1*  invokt  syndt 

«/ 

Idtfint  .LRI6HT 

26 

/•  tovt  right  past  idtntical  siblings 

»/ 

Idtfint  LLEFT 

27 

/•  tovt  loft  past  idtntical  siblings 

*1 

Idtfint  REDRAB 

28 

/•  dtar  scrttn  and  rtdrau  it 

#/ 

NHiH  SAVE 

29 

/•  savt  all  currmt  changts 

•/ 

•dtfina  .KITE 

30 

/•  oritt  to  any  givtn  lilt 

*/ 

Mtfiat  JUT 

31 

/•  wit  adit  station  (last  coooand) 

*1 

struct  ttra_info  l 

ist 

lints, 

/•  lints  par  scrttn 

*1 

chars, 

/•  characttrs  par  lint 

»/ 

utizt. 

/•  uindou  tilt 

»/ 

uitSll 

/*  (rtstrvtd  lor  wpantioni 

♦/ 

char 

cadsC32](Sl, 

/•  coooand  input  stqutnct  strings 

♦/ 

/*  tirtinal  control  output  stqutnctt: 

»/ 

init(16], 

/•  ttrainal  initialization 

*/ 

taht81, 

/*  tab  display  string 

*/ 

•lidtl81, 

/•  tl i sion  display  string 

•/ 

divIBl, 

/•  uindou  dividor 

*/ 

clrlBl, 

/*  cltar  scrttn 

#/ 

posIBl, 

/*  position  cursor 

•/ 

toltS], 

/•  tratt  to  tnd  of  lint 

t  / 

dctai, 

/•  dtlatt  characttr 

»/ 

rtvIBJ, 

/•  tnttr  rtvtrst  vidto  aodt 

»/ 

nortlB], 

/•  wit  rtvtrst  vidto  todt 

*/ 

iontai. 

1*  tnttr  instrt  characttr  oodt 

•/ 

iofftBl, 

/*  wit  instrt  characttr  aodt 

t/ 

11181, 

/*  instrt  lint 

*/ 

dltS], 

/•  dolttt  lint 

t/ 

finitl6]| 

/•  ttrtinal  tartination 

#/ 

>1 
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/ttmtttmttmtmttmmtmtmmmtmmtmttttttttxmttt/ 
/»  */ 


/• 

SYMBOL. H 

•/ 

/♦ 

Syabol  tibia  itructura  for  coapilar  ganention. 

*/ 

/• 

•/ 

/MHHHHHHMHtHIHHHHHHHHHtHHIMHtHtHHIHMHm/ 

•tract 

•ya. tibia  ( 
int 

/•  tyabol  tibia 

*/ 

tya.node, 

/•  noda  'pointer*  to  identifier 

»/ 

•ya.laval, 

/*  lax  ltval 

i/ 

tya.iddr, 

/•  offiat  iddran 

*/ 

•ya.typel 

/•  syabol  type 

*/ 

untlgned  aya.flagtf 

/•  lyabol  tibia  flags.  dMcribad 

»/ 

/•  baloN. 

»/ 

)» 

Mafina  SYMBOLS  30 

/*  tyabol  tibia  tlse 

#/ 

fHHHHHMIHHHIHHIHmtHiWimtHIHtlHMMHMIWHIM/ 


/• 

«/ 

/* 

tyabol  fligt 

*  utad  to  give  aora  inforaition  ibout  i 

•/ 

/» 

tyabol  naae. 

•/ 

/* 

•/ 

Mafina 

TYPE.VfW 

0x0001 

/•  tyabol  it  •  variable 

•/ 

Mafina 

TYPE  CONST 

0x0002 

/a  tyabol  it  •  conttmt 

*/ 

Nafina 

TYPE.PMC 

Ox 0004 

1*  tyabol  it  •  prxadura 

*/ 

Mafina 

TYPE. INI T 

0x0008 

/•  tyabol  aat  initial izad 

»/ 

Mafina 

TYPE.TYPE 

0x0010 

/•  tyabol  it  •  typa  naaa 

•/ 

Mafina 

TYPE.FUNC 

0x0020 

/♦  tyabol  it  •  function 

*/ 

JHHWWtHHHHHIMIIIHHHIHHWHmilWimtHWIHHH/ 


/* 

»/ 

/• 

viriabla  typat  -  pradafinad 

*/ 

/♦ 

•/ 

/•HWHHHWHHWHIWHHHWIIHHHHHWHHIIHWWH/ 


Mafina  TYPE  INT  1 

Mafina  TYPE  CMM  2 

•Mint  TYPE  BOOL  3 
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/» 

*«**/ 

«/ 

/*  ASA1.H 

♦/ 

/• 

*( 

**«•/ 

lindudo  "lyndt.h* 

/•  lyttM  global  i Monition  itructuroi  */ 

•include  ’code.h* 

/*  codo  gonontion  itructuroi 

♦/ 

lindudo  '•yabol.h* 

/«  lyobol  table  itructuroi 

»/ 

•indudo  ‘typos.h* 

/•  production  typo  definition* 

*/ 

oitorn 

•truct  codo.oord  acodoi 

/*  pseudo-code 

*/ 

oitorn 

■truct  lyo.tablo  tiyotool) 

/•  lyobol  table 

*/ 

oitorn 

int  codo.ptr, 

/•  indoi  of  noit  codo  coll 

*/ 

»y«.ptr, 

/•  top  of  syabol  table 

*/ 

lovol, 

/*  current  lnical  lovol 

»/ 

off»et, 

/*  current  offset  in  lovol 

*/ 

rot.lit , 

/*  return  lilt  for  tub-prograos 

•/ 

rot.typo, 

/*  return  typo  for  a  function 

•/ 

body_typo| 

/*  current  sub-proqraa  typo 

*/ 

•ittrn 

eh«r  *typ*ftLA8T.PR0DJ( 

«no*on,fbool_*ip,iint_tipl 


I*  production  type*  »/ 

/*  frequent  >111191  strings  »/ 
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Mafia*  Ml  0 
Mafia*  PLUS.  1 
Mafia*  MINUS  2 
Mafia*  DIV.  *  3 
Mafia*  NEQ.  4 
Mafiaa  LES_  5 
Mafia*  LEO.  & 
Mafia*  EflU.  7 
Mafia*  6RT.  8 
Mafia*  GEO"  9 
Mafia*  AND.COM1.  10 
Mafia*  A.STNT  12 
Mafiaa  CONST.  IS 
Mafia*  DEC  NUN  16 
Mafia*  DECL.  17 
Mafiaa  ELSIF.P.  18 
Mafiaa  IF.STNT.  21 
Mafiaa  I  CLAUSE  23 
Mafia*  LP.STNT.  24 
Mafia*  NAME  26 
Mafiaa  N.EXP.  27 
Mafiaa  OS.COM>.  28 
Mafiaa  P.CALL.  31 
Mafia*  P  COMP  32 
Mafia*  RELATION.  33 
Mafiaa  U  OP  36 
Mafiaa  REN.  34 
Mafiaa  NOD  23 
Mafiaa  AND  THEN.COHP.  11 
Mafiaa  OR.ELSE.COM>.  29 
Mafia*  XOR  COHP  37 
Mafiaa  INTEGER  22 
Mafiaa  BOOLEAN.  13 
Mafia*  CHAR  LIT  14 
Mafia*  IKNT.  20 
Mafia*  TRUE  33 
Mafia*  FALSE.  19 
Mafia*  F  BODY  38 
Mafia*  F.CALl.  39 
Mafia*  P  BODY  30 
Mafia*  RET  STNT  40 
Mafia*  BOOLEAN.VALUE.  41 
Mafia*  EXPON.PART.  42 
Mafia*  A88.PRINARY.  43 
Mafia*  NOtJpRIMRY.  44 
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/«  pseudo-code  word  description 

>444/ 

4/ 

•truct  code.eord  ( 

char 

c.opcode,  /•  operstion  code 

4/ 

c  label t  /*  label  indicator 

4/ 

int 

c.opl. 

/ 4  first  operand 

4/ 

c.op2, 

/•  second  operand 

4/ 

c.nodel 

/•  'pointer*  to  AST  node 

4/ 

/ ♦  ehicb  generated  the 

4/ 

>5 

/a  the  code  uord. 

4/ 

tdef in*  MOODS 

312 

/ •  code  table  siie 

4/ 

/44444444444444S44444444444444444444444444444444444444444444444444444/ 

/ 4  pseudo-code  instruction  opcrition  codes 

4/ 

/  4 

TOP  « 

top  of  stack 

4/ 

/ 44444444444444444444444444444444444444444444444444444444444444444444/ 

(define  .LAB 

0 

/s  eark  code  aord  for  label  (no  code) 

4/ 

(define  1HP 

1 

/s  junp  to  opl 

4/ 

(define  CPY 

2 

/*  copy  TOP 

4/ 

(define  .STO 

3 

/s  [  level  opl ,  offset  op2  1  *  TOP 

4/ 

(define  .CAL 

4 

/•  call  subroutine  op2  at  level  opl 

4/ 

(define  _JPC 

3 

/•  juap  if  TOP  false  to  opl 

4/ 

(define  .EOU 

A 

1*  set  TOP  »  (TOP-t  «■  TOP) 

4/ 

(define  .NEB 

7 

/s  set  TOP  •  (TOP-1  !•  TOP) 

4/ 

(define  .LES 

8 

/•  set  TOP  »  (TOP-l  <  TOP) 

4/ 

(define  .LEO 

9 

/s  set  TOP  «  (TOP-1  <•  TOP) 

4/ 

(define  _6BT 

10 

1*  set  TOP  «  (TOP-1  >  TOP) 

4/ 

(define  .6EB 

11 

/«  set  TOP  «  (TOP-1  >■  TOP) 

4/ 

(define  .IKB 

12 

/*  set  TOP  «  -(TOP) 

4/ 

(define  .ADD 

13 

/•  set  TOP  •  (TOP-l  ♦  TOP) 

4/ 

(define  .SUB 

14 

/•  set  TOP  ■  (TOP-l  -  TOP) 

*1 

(define  .MIL 

13 

/s  set  TOP  •  (TOP-l  ♦  TOP) 

4/ 

(define  .DIV 

1A 

/s  set  TOP  ■  (TOP-l  /  TOP) 

4/ 

•define  .LIT 

17 

/s  set  TOP  ■  egi 

#/ 

(define  .LOO 

18 

/*  set  TOP  ■  C  level  opl!  offset  op2  1 

4/ 

•define  .RET 

19 

/ a  return  fro*  subroutine 

4/ 

•define  .AND 

20 

/t  set  TOP  «  (TOP-l  A  TOP) 

4/ 

(define  .00 

21 

/s  set  TOP  •  (TOP-l  1  TOP) 

4/ 

(define  .NOT 

22 

/s  set  TOP  ■  !  (TOP) 

1/ 

•define  .DCS 

23 

/ s  stack  pointer  -*  opl 

4/ 

•define  .NO 

24 

/•  sot  TOP  ■  (TOP-l  sod  TOP) 

4/ 

(define  REN 

23 

/ •  set  TOP  ■  (TOP-l  ree  TOP) 

4/ 

•define  AND  THEN  2A 

/s  juep  if  TOP  false  to  opl 

4/ 

•define  .0B.EL8E  27 

/t  juep  if  TOP  true  to  opl 

4/ 
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Idtfine 

J  08 

28 

/«  set  TOP  *  ('TOP-1  4  TOP) 

(TOP-1  4  !TOP)*/ 

•define 

ABS 

29 

/*  sit  TOP  «  abs (TOP) 

*/ 

•define 

JIP 

30 

/♦  set  TOP  *  (TOP-1  »•  TOP) 

1/ 

•define 

.NOOP 

31 

/»  no  operition 

*/ 

APPENDIX  F 


/ItMMHHHIHHIlHHHHHHHHItlHHiiiHHHHKHHHMiHI/ 


I*  »/ 

/*  ctypi.h  -  qlobil  dtfintt  tnd  on*  line  function*  #/ 

/•  replicis  the  UNIX  fill  ctype.h  */ 

/«  */ 

/IHHIHimHHHHWHHHtHHHtiilHHHHHIWtHmWim/ 


Mifini  _U  01 

tdifini  _L  02 

Mifint  _N  04 

Idifint  _S  010 

•define  _P  020 

Idifint  _C  040 

Nifini  .1  0100 

Mtirn  ctur  .ctypi.U) 


Idtfim  iulpht(c) 
Mcfini  i eupper <c) 
Mifint  islcwer <c) 
Idifint  iidigitlc) 
Mifim  iudigitk) 
Mifint  iiiptct(c) 
Nifini  iipunct(c) 
Mifim  iulnm(c) 
Mifint  isprint(c) 
Idifim  iuntrl(c) 
Mifim  iutcii(e) 
Mifim  tUKii(c) 


H.ctypi.iMcJM.Ul.D) 
((.ctypi%l»tcH.U) 
((.ctypi.illlcH.U 
<  (_ctypi_+l>  tc3li_N) 
((_ctype_*l)£c34<_Nt_X)) 

((  ctypi  *l)[c](  i) 
((.ctypi.MKcH.P) 
((.etypi.iUlclMJII.L!  H>> 

( (.ctypi.il)  tclK.Pl.UI. II. N)) 
((.ctypi.iDtclI.C) 

( (unsigned) (c) <«0177) 
((t)40177) 
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/HHmHHiHHHHtlHHitHtltitHKKHHHHHitHtltltHHIlitOI/ 
/♦  */ 

It  00000  00  00  00  00  00000  00000  */ 

/•  00  00  00  000  00  00  00  00  »/ 
It  00000  0000  00  0  00  00  00  0000  tl 

I*  00  00  00  000  00  00  00  ♦/ 

/*  00000  00  00  00  00000  00000  ♦/ 

/*  »/ 

/*  SYNtax-Directed  Editor  (cl  Copyright  Oeceeber  1982  */ 

I*  CAPT.  Scott  Edward  Ferguson,  USAF,  AFIT  SCS-82D  */ 

It  Nodi  tied  October  1983  */ 

/*  CAPT.  Michael  L.  NcCricken,  USAF, AFIT  6CS-83D  «/ 

It  «/ 

/•  CONPIIER.C  «/ 

It  SYNDE  systee  coepiler  entry  point.  To  be  linked  with  C0NP1LE.C  »/ 
It  md  appropriate  language  specific  coepiler  routines  to  produce  </ 
I*  a  language  specific  coepiler.  «/ 

/«  «/ 

♦include  ‘synde.h*  It  syetee  global  inforeation  structures  «/ 

♦include  ‘types. h*  /t  production  type  definitions  */ 

•»tern  /a  source  file  inforeation  */ 

struct  file.info  srcjnfol  It  in  AST.C  */ 

char  »noson,ebool,exp,tint_expj 
char  etypes  [LAsfpRODJj  ’ 
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/mmtmmmmfmmmmmtmHttmtmtfttmmmmtm*/ 
/ 1  */ 

/»  uin  «/ 

/*  Entry  point  and  driver  ior  compiler.  */ 

/#  •/ 

•ain(argc,argv) 

int  arge)  /a  input  arguatnt  count  •/ 

char  »argvU)  /»  input  arguaont  ptn  •/ 

I 

put *< "COMPILER  11/11/03*11 


if  (arge  <  2)  /•  check  for  source  file  naae  »/ 

I 

putsCUnspecified  source  file.")! 
exit  Of 

} 

/«  initialize  */ 

if  (la.initUrgvtl))  »»  ERROR)  il  ls,init(src_info.f  Jang)  »■  ERROR)! 
exit  0 1 

coeplledi  /*  generate  pseudo-code  for  interpreter  */ 

a.urapOi 
t.xrapOl 

if  (ire  info.f  edit) 

{ 

eicc 1 ( ' synde* i ' synde  * , argvl 1 1 , 2 )  1 
puts ("Cannot  access  SYNDE. ")f 
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/»- 

/* 

/* 

/* 

/# 

/* 

/# 

/# 

/* 

/# 

/« 

/» 

/♦ 

I* 

/i 

/i 

/# 

/*♦ 


00000 

00  00 

00 

00 

00000 

00000 

00 

00  00 

000  00 

00  00 

00 

00000 

0000 

00  0  00 

00  00 

0000 

00 

00 

00  000 

00  00 

00 

00000 

00 

00 

00 

00000 

00000 

SYNtax-Directed  Editor  (c>  Copyright  Deceaber  1982 
CAPT.  Scott  Eduard  Firquson,  USAF,  AFIT  8CS-82D 
Modified  October  1983 

CAPT.  Niched  L.  HcCrecken,  USAF,  AFIT  6CS-83D 
COMPILE. C 

SYNDE  eyitee  generic  entry  point  and  utility  routine!  for 
coapiler  uie. 


*»/ 
*/ 
*1 
*1 
t  / 
*/ 
»/ 
*/ 
*/ 
»/ 
«/ 
»/ 
«/ 
♦/ 
«/ 
*/ 
*1 


(include  'synde.h* 

1*  systee  global  inforaation  structure! 

i  *1 

(include  'code.h* 

/*  code  generation  structures 

*1 

struct  codeword  *code| 

/•  pseudo-code 

«/ 

(include  'syehal.h* 

sysbol  table  structures 

*/ 

struct  sys.table  tsyebol) 

/•  sysbol  table 

»/ 

extern 

/*  source  file  data 

t/ 

struct  file.info  src  jnfoj 

/*  in  AST.C 

1 1 

extern 

/•  node  production  types 

t/ 

char  stypesill 

/•  in  language  specific  cospiler 

•/ 

int  code_ptr, 

/*  index  of  next  code  cell 

»/ 

*Y«.ptr, 

/*  top  of  sysbol  table 

t  / 

errors, 

/*  error  count 

t/ 

level, 

/»  current  lexical  level 

»/ 

offset, 

/ *  current  offset  in  level 

»/ 

body.type, 

/•  current  sub-progras  type 

*/ 

ret .type, 

/«  return  type  free  a  function 

»/ 

r*t_Ist| 

/*  return  list  froa  a  sub-progras 

»/ 

BOOL  gerror, 

/*  code  table  overfloe  error 

*/ 

serrorl 

/»  sysbol  table  overfloe  error 

*/ 
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/HHHHIHWIHHHIHHHHHHIHHHHHHIHiHMHHIHHHiHH/ 
/*  */ 
/*  coapile  */ 
It  Initial iz*  compilation  and  gtnerati  cod*.  #/ 
/*  */ 
/eeesteeeeaMseteeaeeetteetsetsHeeesesetttHseeeeesseetHaetseMssesttt/ 

coapiltO 

{ 

REG  aiial  /»  cod*  size  in  bytes  «/ 
char  code.naaetfOl)  /*  cod*  file  naa*  •/ 
FILE  acode.Filei  /*  cod*  file  daacriptor  */ 
int  i| 


error*  ■  level  •  <ya.ptr  ■  coda.ptr  •  0) 
gtrror  »  itrror  ■  FALSE) 

/•  allocat*  a  daar  space  For  coda  generation  aaaory  */ 

if  I! (coda  *  aallodsize  *  sizaof (struct  codeword) attGRDS))) 

{ 

putsflnsuFFidant  aaaory  For  coda.*)) 
raturn  ERROR; 

) 

/*  allocate  a  dear  space  For  syabol  table  aaaory  •/ 

iF  (Msyabol  •  *allx(sizeoF(struct  sya  tabl •> aSYNBOLS) > ) 

{ 

putsCInsuFFicient  aaaory  For  syabol*. *) ) 
raturn  ERROR) 

> 

For  (i  ■  S|  i  <•  9)  /«  daar  all  a" or  Barkers  */ 

iF  (src.inFo.F.earktil) 

clr.aarKsrc.lnFo.F.earkCUU 

goal(src.inFo.F.root))  /*  goal  */ 

It  delate  old  code  File  and  save  nee  one  */ 

strepy  (code.naae,  src.inFo.  F  juae)  | 

street (code.naae, '.cod* I ) 

put s(* Coda  File  ■  *))  puts (code.naae) I  puts(*.*)| 

unlink (code.naae) I 

iF  ((code.File  ■  creat (code.naae, 0444))  ERROR  II 
erltelcode.File, code, size)  ••  size  II 
dose(code.File)  >■  ERROR)  ( 
ioerrlcode.FileM 

puts  I ‘Cannot  generate  code  File.*)) 
return  ERROR) 

} 

Free(syaboD)  It  Free  syabol  table  (leave  code)  */ 

return  errors; 

) 
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/ateetettttettteeeeetttetteaeaeeeeteeeeeeeeeeteaeeaeeeeeteeeteeea  aaaaaaa/ 


/a 

a/ 

/a 

collect 

•/ 

/a 

Collect  the  ’ut’ 

•ynPelt  in  a  tilling  lilt  into  the 

•/ 

/a 

•applied  itring. 

Return  ERROR  if  an  unutiified  and 

•/ 

/a 

unconditional  ut 

flaunt  node  ii  encountered. 

a/ 

/a 

a/ 

/HHtHHIHWHItHHItWtWWHHMHIlHHHWHHWMHtHM/ 

int  coll  act (node, »tr> 
int  node! 

char  Htr{ 

{ 

RES  next) 

next  *  ton (node) j 
for  <  J  |  )  { 

if  (value(next)l 

Htr+*  ■  value(next))  /•  trannfer  character  a/ 

flu  if  (IchMlag  (next, OWN))  { 

**tr  «  0| 

rtturn  ERROR}  /a  unnatisfied  uncontf  ut  a/ 

) 

if  fchk_f iaq (n>xt,RTI10ST> )  ( 

»itr  ■  0) 

rtturn  SUCCESS!  /a  done  a/ 

) 

next  »  right  (nut){ 

> 

) 
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/mHWIHHIWHIHWWIlHHIMlWIWIlHMWIWIHHHHIW/ 
/♦  *1 
It  coapare  •/ 
It  Coapare  tht  tereinal  ’*et’  children  of  too  identifier  »/ 
It  noin.  Roturn  TRUE  if  equal.  Roturn  ERROR  if  an  «/ 
It  uMitiofiod  and  unconditional  tet  eleaent  nodt  ii  ti 
It  encountered.  •/ 
It  tl 


/IHHHHHHIHIHHimiWHMtOHIHHHIMIItHHHHMHHIIW/ 


int  coapare(nodel,node2) 
int  nodal, 
noda2| 


( 

char  idl(401, 
id2C40J( 


/•  noda  ’pointer*'  •/ 


if  (collKt(nodal,idl)  ■■  ERROR  II  collKtinoda2,id2)  ■■  ERROR) 
return  ERROR; 
if  (*trcap(idl,id2)) 
return  FALSEl 
return  TRUE; 

) 

liittttttitiittittttttttittttttttttttmmttttttttttttttttttttttttitttti 


It 

tl 

It 

nuaher 

tl 

It 

Convert  the  terainal  ’tat’  children  nuaeric  value*  froa 

tl 

it 

an  integer  node  and  return  the  unsigned  nuaeric  value. 

tl 

It 

Return  ERROR  if  an  unut i died  and  unconditional  *et 

tl 

it 

eleaent  node  it  encountered. 

tl 

It 

tl 

nuaher (node, bate) 


int  node, 

It  ’pointer*  to  tubtree 

tl 

bate) 

( 

REI  actual 

It  nuaeric  bate 

tl 

It  accuaulatod  value 

tl 

char  ch| 

It  digit  froa  tet 

tl 

int  ne»t| 

It  eibling  chain  ’pointer’ 

tl 

nnt  *  ton  (node); 

accua  ■  01 

for  <  |  |  )  ( 

It  accuaulate  digit* 

tl 

if  (Meh  ■  value(neit))  U  !chk_fleg(neit,ORER)) 

return  ERROR)  It  eiit  if  untatitfied  unconditional  *et */ 
if  (i*nuoeric(toupper(ch),baH))  /*  te»t  bate  validity  */ 
accua  ■  aceua  •  bate  ♦  ((eh<»’0')  ?  ch-'O’  ;  ch*59)| 
if  lchk_flag(neit,RTB08T)) 
return  actual 
neit  ■  right (nett) | 
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) 

} 


/#  »/ 

/»  gen  •/ 

/*  Generate  i  pwudo-cod*  instruct  ion  or  Ubtl.  Roturn  •/ 

/#  tho  addreii  of  tho  generated  wwd.  *1 

/•  •/ 

/IHHHMHHIHtHHIHHHiHHHIHHIHHfHHHHHIHHMHHHM/ 

gen (opcode, op l,op2, node) 

int  opcode,  /•  pwudo-inetruction  op-cod*  •/ 

opi,  /e  optrind  1  a/ 

op2,  /*  operand  2  */ 

nodii  /•  nod*  responsible  for  cod*  */ 

{ 

witch  (opcode)  ( 

cat*  .LAB:  codelcode.ptrl.c.label  ■  TRUE) 


caw  _N00P:  return  code.ptr) 

default:  if  (cod*_ptr  >■  WORDS)  { 

if  (Igerror)  ( 

puts ('Code  table  overflo*.')) 
♦•♦error  i  i 
gerror  »  TRUE) 

) 

return  code  ptrf 
) 

codetcode.ptrl.c.opcod*  «  opcode) 
codetcode.ptrl.c.opl  «  opl) 

cod*(code.ptr].c.op2  ■  op2| 

codetcode.ptrl.c.nod*  »  node) 
return  code  ptr**) 

) 

} 

/teeeeteeeeeeeeeeeeeeeeeeeeeMmeteteeteeeeHeetettteeeeteefeeeteettf**/ 


/#  *1 

I*  fix  */ 

/*  FU  a  foruard  reference  by  wtting  opl  of  the  juep  */ 

/*  inetruction  at  the  epecified  addreee  to  the  current  */ 

/*  code.ptr.  */ 

/#  •/ 

/HimwmHHHiKHiHHiimttHHwmimmimiHWdtmm/ 

fii(addr) 

int  addr) 


<  /♦  fii  juep  and  eark  label  * I 

codetcodeladdrl.c.opl  ■  code.ptr ] . c.l abel  •  TRUE) 

) 
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/mttmmmmmmmmtmmmtfmmtimttmmttmfmtt/ 
/«  ♦/ 
It  find  tl 
/•  Find  i  *yebol  in  the  lyebol  tabic.  Raturn  the  tyabol  */ 
/*  table  index  or  ERROR  if  not  found.  */ 
It  ti 


/mammtmitmmtmmmtftttttttttttmttttmtmttttmttttt/ 

find (node) 

int  node) 

( 

RES  t I  I*  lyebolt  index  */ 


for  (i  ■  »ye.ptr  1  i  )  — il 

if  (coapare<iyabol[i].*ye.noda,node)  »■  TRUE) 
return  it 

return  ERROR) 

1 


It 

It 

It 

It 

It 


place 


Place  a  new  i tea  in  the  ayobol  table, 
syebol  table  index. 


Return  the  new 


•/ 

♦/ 

•/ 

tl 

tl 


/•eeteeeeeeeeeteeetet*e<eeeeeee*»«*»**ti***ttte**eteee*ft*eteet*ttttte«t/ 


int  pi ace (node, type) 
int  node, 
typerj 

{ 

if  (*ye.ptr*l  >»  SYMBOLS)  (  It  lieit  eyebol  count  */ 

if  (!mrror)  ( 

putiCSyabol  table  overflow.*)) 
terror  •  TRUE) 

♦♦erwi) 

> 

) 

elee  ( 

xyebol [ t+«ye_ptr ) . lye.node  •  node! 
eyebol Uye.ptrl.»ye.level  ■  level) 

•yebelUye.ptrl.eye.addr  ■  offeet++| 

•yebeltiya.ptrl.eye  type  ■  type) 

1 

return  lye  ptr) 

} 
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mg 


/* 

»/ 

/» 

trror 

«/ 

/» 

Hark  tha  aptcifitd  nodt  with  an  trror  and  output  tht 

*/ 

/• 

supplied  trror  amagt.  Rtturn  TRUE  ahtn  ail  trror 

«/ 

/» 

aarktri  havt  bttn  uitd. 

•/ 

/• 

/•(••I 

•/ 

IHt/ 

/•  nodt  in  trror  «/ 

/*  «rror  atuagt  string  »/ 

/•  aarktr  indu  */ 

/»  find  th»  firit  optn  trror  tirktr  or  rtutt  ont  with  th»  mu  nod*  */ 
for  (i  *  5} 

i  <•  8  U  arc.info.f.aarkM  U  src  info.f  tarkfil  !»  node) 

♦♦i ) ; 

put* ('ERROR  MARKER  *)|  /♦  atiaagt  §/ 

putcharti+'OMl  putaC!  •)} 
puts(str) f  puts ( * . " ) | 
if  (arejnfo.faarktii) 

clr_aark<noda)|  /*  claar  any  prtvious  atrk  #/ 

,*Ul*9<*rc_info.f_aarkti]  •  node, MARK)  j  /t  i§t  trror  aarktr  1/ 

{ 

putt ('Error  liait  ixcttdtd.'U 
raturn  TRUE! 

} 

♦♦arroral 
raturn  FALSE} 

> 


int  trror (nodi, str) 
int  nodal 

char  aatri 

{ 

RE6  i{ 
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/ihhhhhhihhhhhhhhhhihhihhhiihhhihhhhhhhh/ 
/*  */ 
/*  node.typ*  »/ 
/*  Return  nod*  type  of  th*  node  specified.  */ 

/•  */ 


int  node.type(node) 
int  node! 

{ 

RE8  i|  /•  types  indcs  .  </ 

int  loci 

loc  ■  s.ptrUinkdinklprodtnod*))))!  /•  string  location  is  in  ttbl*  */ 


for  (i  «  0|  typestili  ♦♦i) 
if  (typesCi 3  *»  loc) 
return  ii 

return  ERROR)  /•  not  found  */ 

> 

/IHHHHIttmHHIHHIHHHKHHiHtKHfllKIHtMiHHHHIHHt/ 
/*  »/ 

/»  fill.typos  */ 

/*  Fill  types  errey  with  string  locetions  in  syntex  */ 

/»  description  corresponding  to  strings  in  trguoent.  */ 

/*  s  / 

/SHeeHeettesestttstssttfsssftstfstssfssseittssstestststststetstftstft*/ 


fill  types 0 
< 

register  cher  «s( 


int  ii  /*  types  index  »/ 

for  (i  »  Oj  typestili  ♦♦!)  (  I •  stop  st  0  entry  «/ 

s  ■  s.ptr(link(4));  /s  loestion  of  first  string  «/ 

/•puts (typMl i 3 > |  like  this  into  s  non  coeeent  to  find  errors */ 

/•  in  the  types  trrsy.  «/ 

fflush(stdout)) 

while  (strcagitsy typesCi 3) )  (  I*  while  strings  not  equsl  »/ 

if  (#s  »»  OxFFFF)  {  /*  error  if  no  tor*  in  SOF  •/ 

putsl'Type-fill  error!  Mi 
putsttypesCi 3I| 
exit!)) 

) 

while  (#*♦♦)  |  /*  find  next  SOF  string  # / 

> 

typesti]  ■  s|  /•  type  is  Ik  of  SOF  string  */ 

> 

} 
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•include  "idil.lt' 


/tHHHHUlHHHMHHHHHHHtllHiHHHHIHHMHHHHHHt/ 
/•  »/ 
/*  old  ident(ifier)  *1 

/•  *  »/ 


/imHHHMHIHIHHmtHIHHHHIKHHHHHHHMIHtHHtlll/ 

lot  old_i dent (node) 
int  nodi I 

{ 

RES  ll 

if  Hi  •  find (nodill  !«  ERROR) 
rtturn  i| 

if  (error (node, "undeclired  identifier") ) 
rtturn  ERROR; 

return  plice(node,TYPE_VAR)( 

> 

/•MMMiimiiiMiMMMMiiiiiiitttiiiiiiiitiiitttiiiiiiiiiiiiMti/ 


/»  »/ 

/•  ne«_i dent (i fieri  </ 

/•  UndteUred  identifier  itirch.  Return  ERROR  if  the  •/ 

>•  identifier  it  found  in  the  tyebol  table  it  the  current  t / 

/•  level,  otheruiie  enter  it  u  t  neu  lyebol  tnd  rtturn  «/ 

/•  the  tyebol  tible  index.  •/ 

/*  •/ 

/•HMiMitMitMittiitHiMMiMitiHfiiiiitiiiiiiiiitiitiilttitiM/ 


int  ne«_i dent (node) 
int  nodel 

( 

RES  il  /*  tyebol  tible  index  */ 

/*  euit  not  be  it  nee  level  */ 
if  Hi  ■  find  Inode))  !■  ERROR  bit  eyeboUil.  tye_  level  »■  level) 
if  (error (node, "identifier  tlreidy  decltred*)) 
return  ERROR) 

return  pi  ice  (node,  0);  / *  pUct  new  tyebol  •/ 

) 


/eeeHteeeeteeeeeeeeeeeteeteeHeeeeeteefeeeeeeeteteeeeeeeeteeeeeeeee  / 
/•  «/ 
/•  integer  */ 
/»  •/ 
/eeeeeeeeeeeeeeeeteeeeteeeeeeeteeeteeteeetfeteteeeeefeeeeeeteeeeeeee/ 


int  integer (node) 
int  nodel 

( 

return  nueber (node, 10) I  I*  bite  10  nueber  »/ 
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} 


/*  »/ 

/*  n.exp  •/ 

/*  *  4/ 

/444444444444444t4tt44444444444444444444444444t44444444444444t444444/ 


int  n_»xp(nodt> 
int  nod*} 

{ 

riturn  expUonlnodt))  j  /•  (expression)  »/ 

) 


/t**ttt*4ttt**t4ttttttttt44t4tttt*tttt44tttttttttttttttt44t44t4tt*tt/ 
/4  4/ 
/4  dtc.nut  •/ 
/4  4/ 
/ 4444444444444444444444444444444444444444444444444444444444444444444/ 


int  dec.nua(nodt) 
int  nod*| 

{ 

rtturn  integer (son  Inode))} 
) 


/ 4444444444444444444444444444444444444444444444444444444444444444444/ 


/  4  4/ 
/4  *Ul_OP  4/ 
/4  4/ 
/4444444444444444444444444444444444444444444444444444444444404444444/ 


int  aul.op(node) 
int  nod*} 

< 

if  ( ! son <nod*> ) 
if  (trror<node,noton)) 
return  ERROR) 

•It* 

r*turn  _HUL| 

witch  (nod*  typ*(*on(nod*)l) 

< 


cm  MIL.: 

/*  •*• 

4/ 

return  JWLJ 
cm*  Div_: 

/*  V 

4/ 

return  _0IV| 
cm  RED.! 

/*  "REIT 

4/ 

return  .RED) 
c*m  MO.: 

/*  *MD* 

4/ 

rtturn  MO) 

) 
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/»  priury  ,/ 

'*  *1 


int  prisary(node) 
int  node) 

{ 

RES  next! 

int  i; 

if  (!(n»xt  ■  ion (nod*))) 
if  (error (node, noson)) 
return  ERROR; 
else  { 

gen(.lIT,i,0,nodt)j 
return  TYPE  INT; 

) 

Mitch  (node.type(next))  { 

cim  DEC_NUH_>:  n  <deciaal_nuaber>  »/ 

if  (<i  ■  dac.nua(naxt))  ««  ERROR) 
return  ERRORi 

gen(.LIT, 1,0, next);  /»  laid  literal  #/ 

return  TYPE.IRT; 

can  NANE_:  /a  <niBt>  t/ 

if  ((i  ■  naM(next))  »  ERROR) 
return  ERRORI 

if  (!(syabol(i].sya.flags  Ik  TYPE.VAR))  I*  VAR  or  CONST  »/ 

if  (error (next.’aust  he  constant  or  variable  naae*)> 
return  ERROR; 
elsa  < 

gen(_LlT,i,0,next)| 
return  TYPE  INT; 

> 

gan ( .100, 1 evel -lyabol l i J . aya.l aval , syahol 1 i 1 . iya  addr , next) I 
return  syahol lil.sya. type;  it  load  variable  »/ 

caM  R.EIP.:  it  <nested.exp>  «/ 

return  n  exp (next II 
cast  CNRR.LIT.  : 

if  <(1  ■  char. lit (next))  •»  ERROR) 
return  ERRORI 
gonl.UT'i'O'aeit); 
return  TYPE  CHRR; 
cast  ROOLEM.VRLUE.  : 
if  <(i  ■  bool .val (next))  ■■  ERROR) 
return  ERROR; 
gen(.LlT,i,0,neit)| 
raturn  TYPE.IOOLl 
cast  F.CRU.  1 
raturn  fane  .call  (nwt)| 
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} 

) 


/•  character  litaral  *' 

I*  *l 

/IHHHHMMHiHHHaWHIHIHIHHHHHHHMIHHIHIHHIHt/ 


int  char.lit(node) 
in t  nodal 


( 

int  nntl 

next  ■  ion (node) | 
if  <chk_f laq<ncxtyOPEN) ) 
if  (error Inext, 'character  needed*)) 
return  ERROR) 

also 

return  0| 

elie 

return  valuelnextll 

) 

/•*ef*H#«teMe**t*a*ee«»«»aM*aM»»**«»t«*«*tt*M  »«***#*#«****•*•*#•/ 
/• 

I*  boolean  value  *> 

I •  #/ 

/IHHHIHeilWHIMHHIHHHHOHHHIKMIHHtHtMiimtHIt/ 

int  bool.val(node) 
int  node! 


( 

int  nextl 

if  (!(next  *  ton (node))) 
if  (error (next, noeon)) 
return  ERROR! 

el  a* 

return  TRUEl 

if  (node.type(next)  TRUE.) 
return  TRUE) 

elM 

return  FALSE) 

) 
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•include  *adal.h‘ 

/IWHHMHHUlHHtHHHtltlHttlHtHtHHHHfltitlMHHKHH/ 


It  ♦/ 
/*  rel.op  *1 
It  ’  */ 

/»»etteett*t*e«#t«»eeft«t*t#»»e«tt«tHtfMt««#*t*t**t*ttttt«*t#*m«t/ 


int  rel.op (node) 
int  node) 

< 

if  (Ison (nod*)) 
if  (error (node, noson)) 
return  ERROR) 

else 

return  .EQU) 

snitch  (node_type(son (node) ) )  ( 


case  EflU.: 
return  _E6U) 

It  *=• 

tl 

case  NEfl.f 
return  _ME0) 

It  •/*■ 

tl 

case  LES.: 
return  _LES; 

/«  ■<  * 

tl 

case  LEO.: 
return  .LEO) 

/♦  •<*• 

♦/ 

case  SRT.:* 
return  .SRT) 

/*  ■>  * 

t  / 

case  6E0.: 
return  GEO) 

) 

) 

It  •>.• 

tl 

/tttttttttttiittttttttttttittttttittttiitttitttuttttttittttttttttiit  / 


It 

»/ 

It  add.op 

tl 

It 

tl 

eeeeeeet 

int  add.op(node) 
int  node) 

( 

if  (Ison(node)) 
if  (error (node, noson)) 
return  ERROR) 

else 

return  .MB) 

saitch  (node.type (son (node)))  ( 


case  PLUS.: 

It 

tl 

return  .ADD) 

case  MRUS.: 

It  ... 

tl 

return  SUB) 

) 
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/HHiHMHHiHHHmHHKHillfKiHtmtmHIOHHHHiHtlit/ 
/*  */ 
/»  fact(or)§  */ 


/» 


»/ 


/*t*mf**«*mtHm**t*mM**«*m*ttm*t*m*tmmt«t«t*mm/ 


int  facts(node) 

int 

{ 

node! 

REG 

next! 

int 

op, 

type! 

/*  tultiply  operator  »/ 


if  (lop  *  eul.opfnext  «  sen(node)))  »■  ERROR)  /»  <»ul,op>  »/ 

return  ERROR! 

if  ((type  ■  factor (right (next) ) )  «*  ERROR)  /♦  <f»ctor>  */ 

return  ERROR ( 
if  (type  !■  TYPE.INT) 

{ 

error (next, 'integer  type  expected*)! 
return  ERROR! 

) 

genlop, 0,0, next);  /•  eultipiy  operation  */ 

return  type! 

) 


/metmtmemfttemmmmmtttmmttmtttmfetmttftfft/ 


/»  §/ 

/*  rel (ation)al  »/ 

/#  •/ 

/mmtmeemttmmtmtetMfmefmmmteettmttettmteeet/ 


int  rel el (node) 
int  node! 

( 

REG  next! 

int  op,  /*  relational  operators  ♦/ 

typ»J 

if  ((op  ■  rel.optnext  ■  son(node)))  »*  ERROR)  /»  <rel_op>  */ 

return  ERROR! 

if  ((type  ■  ».exp(right(next)))  ■■  ERROR)  /*  <sieple<.exp>  */ 

return  ERROR) 

gen(op, 0,0, next)!  /•  relational  operation  */ 

return  type! 

) 
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/***»*( 

/ 1 

/» 

/a 

tere* 

int  tern(node) 

int 

( 

node; 

RE6 

next; 

int 

OP. 

typ«f 

*1 

*/ 

«/ 

eeeeeeeeeettttemfteeeett***/ 


/*  adding  operator  t / 


if  ((op  «  add_ap(next  «  son (node) ) )  •*  ERROR)  /•  (add.op)  »/ 
return  ERROR) 

if  ((type  *  tera(ri ght (next) ) )  *•  ERROR)  /*  <tere>  */ 

return  ERROR) 
if  (type  !«  TYPE  INI) 

( 

error (next, 'integer  type  expected'); 
return  ERROR; 

) 

genlop, 0,0, next);  /*  adding  operation  */ 

return  type; 

} 


/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeteemeeeeeeeeteeeeeeee*****/ 
/•  */ 
/•  tere  »/ 
/*  ♦/ 
/teeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeteeeeeeeeeeeeeeeeeeeeeee/ 


int  tere(node) 
int  node; 

( 

RE6  neat, ltype, rtypel 

if  ((ltype  ■  factor (next  ■  ion (node)))  ■■  ERROR)  /*  (factor)  e / 
return  ERROR; 

uhile  (!chk.flag(next,RTHOST))  /e  ((factor*))  */ 

if  (!chk.flag(next  ■  right (next), OPEN)) 
if  t (rtype  ■  fact* (next))  ■■  ERROR) 
return  ERROR; 

else  if  ((ltype  !•  TYPE  INT)  II 
(rtype  !»  TYPE  INT) I 

( 

error (node, 'type  aiiaatch.  operation  not  defined'); 
return  ERROR; 

) 

return  ltype; 

) 
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/ttmmtmtmtmttmtmmmttmmtttttmttmHmitttm/ 
/t  «/ 

/•  factor  */ 

/»  #/ 


int  factor (nodt) 
int  nodt) 

{ 

int  ntxt) 

if  (Hntxt  *  ton  (nod*))) 
if  («rror (nodt, noton)) 
rtturn  ERROR) 

•1st 

( 

gtnC.UT, 0,0, nodt); 
rtturn  TYPE. I NT I 

) 

witch  (nodt.typt(ntxU) 

( 

cast  EXP.PRIHARY.  : 

rtturn  txp_pria)ntxt)J 
cut  ABS.PRIHARY.  : 

rtturn  ab§_pria<ntxt) J 
cut  NOT  .PRIMARY.  I 
rtturn  net  pria(ntxt); 

) 

) 
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(include  ‘adal.h* 


/»  *1 
/*  u.op  »/ 

/♦  ’  •/ 


int  u.op (node) 
int  nod* I 

( 

if  I! son (node)) 
if  (error (node, noson)) 
return  ERROR) 

elit 

return  _NOOP| 

snitch  (node_type(son inode) ) )  ( 


case  PLUS.: 

/« 

«/ 

return  _N00P) 

case  MINUS.: 

/* 

•/ 

return  _N£6{ 

} 

} 


/»  •/ 

/•  or.rel(ation)  t  / 

/«  »/ 

/Mfeeefeeffeeteemefmeeetmtmtetmetfmtemetefttmeetft*/ 


int  br.rel(node) 
int  node) 

( 

int  type) 

if  ((type  *  rel stion (son (node) ) )  ■■  ERROR)  /t  (relation)  */ 
return  ERROR) 
if  (type  !»  TYPE  BOOL) 

( 

error  (son  (node) ,  bool  .up) ) 
return  ERROR) 

) 

qen(.0R,0,0,node)|  /*  or  operation  *1 

return  type) 

) 
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/HWIHWHHHWHHHWHHHiHHHIHHWIMWWHHHH/ 
/»  ♦/ 
/•  U.CUUSI  */ 

/*  "  #/ 

/tmtmttmttMmttmtmmfmmtmmtmmmttttttttttt/ 


int  u.cliuse(node) 
int  node! 

{ 


return  exp (son (node));  /»  (expression)  </ 

} 

/HIHWMHHKHHItHIIttHiHtfWtHttWHHIlWimtlHmt/ 
/*  »/ 
/*  and.nl  (it  ion)  •/ 

/«  *  «/ 

/WHWHWtWHIHHIHHHHHIWIHiHWIWHHHIHWHI/ 


int  ind.nl  (nodi) 
int  nodi I 

{ 

int  type) 

if  ((type  ■  nl  ati  on  (son  (nodi) )  >  «•  ERROR) 
return  ERROR; 
if  (type  )«  TYPE  BOOL) 

( 

error (son (nodi) , bool .exp ) | 
return  ERROR; 

) 

gent.AKD, 0,0, nodi) I 
return  type) 

) 

/IWHtlHIHHWIHItHMHIHHWHHHHItHIIHHHiHIHMHI/ 


/t 

«/ 

/• 

and.thm.nl  (ation) 

»/ 

/t 

«/ 

/IHHHHHHHmtMMIHIHHHilHtIHIIIHimMIHHHHHKHI/ 

int  and.tbm.nl  (nodi) 
int  nodil 

< 

int  ltypil 

if  (dtypi  ■  rilition(son(nodi)))  ■■  ERROR)  /•  <ril*tion>  •/ 
return  ERROR; 
if  dtypi  !■  TYPE.BOOL) 
if  (errorisonlnodel'bool.exp)) 
return  ERROR I 
nturn  l  type; 

) 


/•  (relation)  */ 


/•  and  operation  •/ 
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/i  ♦/ 
/*  or.else.rel(ation)  */ 
/«  */ 
/tmttttmtmtttmtttmmmtmtmmttmmtHtittttttmtt/ 


int  or.clsi.nl  (node) 
int  node! 

{ 

int  ltypc) 

if  ((ltypc  ■  rcUtion(son(nodc)>)  «■  ERROR) 
return  ERROR) 
if  (ltypc  !»  TYPE.BOOL) 
if  (error (son (node), bool. up)) 
return  ERROR) 


/«  (relation)  »/ 


return  ltype) 


) 


/itttfmttmmsmmfttmttttmmtttiM* 

/• 

/*  xor.rel (ation) 

/» 


441 

41 

41 

41 

441 


int  nor.rel (node) 
int  node) 

( 

int  ltypc) 

il  ((ltype  ■  rel ation (son (node) ) >  «■  ERROR) 
return  ERROR) 
if  (ltype  !■  TYPE.BOOU 
if  <error<son(node),6ool.exp)) 
return  ERROR) 
gen(.X0R'0,0,nodc)| 
return  ltype) 

) 


14  (relation)  */ 


14  ior  operation  •/ 


14444444444444444444444444444444444444444444444444444444444444444444/ 
/•  4/ 
14  rel(ation).part  a/ 
/*  ♦/ 
14 444444444444444444444444444444444444444444444444444444444444444444/ 


int  rel.part(node) 
int  node) 

{ 

return  relaKson(node))) 
) 


I*  (relational)  a/ 
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/  . . . 

/*  *1 

I *  %  exp  *1 

/•  *1 


int  s.exp(node) 

int 

node) 

( 

RE6 

next) 

int 

op» 

/*  unery  op-code  */ 

typ*l 

op  ■  .HOOP! 

if  (node.typelnext  *  son  (node) )  U.QPJ  { 
if  fciik_fleg(next,OP£N)) 

if  ((op  ■  u.op(nextl)  ■■  ERROR)  /*  Uunery.operetor))  */ 

return  ERROR) 
next  •  right (next) { 

> 

if  ((type  *  tere(next))  »■  ERROR)  /•  <tere>  •/ 

return  ERROR) 
if  ((type  !«  TYPE.INT)  II 
(op  !»  NOOP)) 

( 

error (next, int. exp)) 
return  ERROR) 

) 

gen(op,0,0,son(nodc))|  /•  unery  operition  */ 

while  ( !chk_fliq(n*xt , RTMOST) ) 

{ 

if  (type  !■  TYPE.INT) 
if  terror (nextf int.exp) ) 
return  ERROR) 

if  (!chk.flig(next  ■  right(next) , OPEN) ) 
if  ((type  »  teree(next))  *■  ERROR)  I*  Uteree»  */ 

return  ERROR) 

) 

return  type) 

) 
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/HHIHHHHHHHWHIWtUHmHIHHHIHttmilWiWiHH/ 
It  */ 

It  i.dauM  */ 

It  tj 

/HMHIHHHHHMHWHWHHWIHlWHHHHiHHtHHI «»*/ 


int  i.cUuu  (nod*) 
int  nodal 

{ 


raturn  w  cliust(ton(noda))l  /♦  <*hila  clauia)  »/ 

} 

/aaaaaaaaaaaanaaaaaanaaaaaaaaaaaanaaaaaaaataaanaaaaaaaaaaaaaaaaaaaaa/ 

It  ti 

It  alaajtart  »/ 

/*  '  */ 

lttttttttttttttttttttttttttttttttittitt*i*tttt*tUttittttttttttiitit/ 


int  alitjurtinoda) 
int  nodal 

( 

raturn  aa(|_ot  stati ( son  <noda> )  (  It  <s*qji(  »tat»>  «/ 

) 
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(include  ■adal.h* 


/twttmttttitmttmittttttmtttmttmmmtttttmtmmtMt/ 
/•  »/ 
/»  el  si f. part  ♦/ 
/•  */ 


int  elsif .part(nods) 


int 

node) 

RE6 

next) 

int 

Isbell, 

/•  label  address  storage  */ 

typ«* 

if  ((type  ■  exp  (nut  *  son  (node  I ) )  «■  ERROR)  /«  (expression)  #/ 
return  ERROR) 
if  (type  !■  nPE.WOL) 
if  terror(next,bool_sxpl) 
return  ERROR) 

libel  1  •  gen(.JPC,0,0,0)|  I*  juep  to  next  else  «/ 

if  ( seq.of _stets (r  1  ght (nut) I  »»  ERROR)  /«  <seq_of .stats)  »/ 

return  ERROR) 
return  Isbell) 

} 
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/*  */ 
/*  ind.cotp  * / 

/*  "  */ 
/•MtttMttt*ttMt*t*ttt*4«Hmttmt«tt«tmtm<m«*»tmt*»**t*t/ 


int  ind.cotp (nodt) 
int  nodt) 

( 

REG  ntxt, ltypt) 

if  ((ltypi  >  rilitionlnixt  *  son  (nod*) ) )  ■■  ERROR)  /•  <rtlition>  */ 
rtturn  ERROR) 
if  (ltypt  !«  TYPE.BOOL) 
if  <«rror (son (node) , bool _sxp) ) 
rtturn  ERROR) 

uhilt  ( !chk_f lagfnsxt, RTKOST) >  /*  Kand.rtl))  */ 

if  <!chk .flagfntxt  *  right (ntxt), OPEN)) 
if  ((ltypt  ■  and.rtl (ntxt) )  ■■  ERROR) 
rtturn  ERROR) 
rtturn  ltypt) 

) 


/HtimtfMmitmtmttttfttmtttftttftiMftttmitmtimmm/ 
/*  «/ 

/»  or.cotp  »/ 

I*  ♦/ 

/IHHHHHMHMHiHIHHHHHmiHHHItltlHHHiiltHItlHHt/ 


int  or.cotp (nodt) 
int  nodtl 

( 

RES  noxt, ltypt) 

if  ((ltypi  ■  rilationlntxt  ■  son (nodt) ) )  ERROR) 
rtturn  ERROR) 
if  (ltypt  !■  TYPE.BOOL) 
if  (trror(»on(nodt),bool.ixp)) 
rtturn  ERROR) 

uhilt  (!chk.fUg(nixt,RTIW8T)) 
if  (!chk.flag(ntxt  ■  right(mxt),OPER)) 
if  ((ltypt  ■  or.rtl(nixt))  ■«  ERROR) 
rtturn  ERROR) 
rtturn  ltypt) 

> 


/•  <rtlation>  ♦/ 


/♦  Kor.nl>)  •/ 
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/»  »/ 

/»  ind.thtn.cotp  */ 

/•  *  ♦/ 


/tHttt*t«t*mt**t**tttt*ttt«t**m*tmt*mtmtl*t*tt*«tMt*ttt«t/ 

int  and.thtn.coop(nodt) 
int  nod* | 

( 

KB  n*xt,ltypt,  chain,  label! 

if  Ultypt  •  rilationtnixt  *  son  (nod*) ) )  ■*  ERROR)  /•  <rilation>  */ 
rtturn  ERROR) 
if  (ltyp*  !>  TYPE .BOOL) 
if  (*rror(ton<nodt),bool.txp)) 
rtturn  ERROR) 

chain  *  lab*]  ■  g*n(_LABf0,0,ntxt)) 

Mhil*  ( !chk_f Iaqfn«st,RTHOST) )  /*  Uand.thtn.rtl>>  »/ 

if  (!chk  flag (next  *  right (ntxt), OPEN)) 

{ 

labtl  •  codtllabtll.c.opl  •  g tnl.AND.THEN, 0,0, next) ) 
if  ((ltyp*  *  and.thtn.rel (next))  »*  ERROR) 
rtturn  ERROR) 

) 

do 

r 

labtl  •  codtlchainl.c.opll 
fix (chain) ) 

) 

Mhil*  (chain  ■  label)) 
rtturn  ltypt) 

) 
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/HHHtlHMtHHHIitltHIHHi 

It 

It  or.ilii.coap 
It 

/WHHHMHHHHHHHWHH 

int  or_elie_coep(node) 
int  nodal 

{ 

REB  next, ltypc, chain, label  I 

if  (Utyp*  *  relationlnext  *  son  (node)  I )  *■  ERROR)  It  <relation>  */ 
return  ERROR) 
if  (ltype  !*  TYPEJOOL) 
if  (error(eon(node),bool_exp)) 
return  ERROR) 

chain  ■  label  ■  genl.LAB, 0,0, next) ) 

while  ( ! chk_f 1 ag (next , RTHOST) )  I*  C<or_else_rel»  */ 

if  (!(chk_flag(next  «  right (next! » , OPEN) ) 

( 

label  ■  code! label  3. c.opl  ■  gen(.0R.£LSE,0,0,next)| 
if  ((ltype  «  or_else_rel (next) )  “  ERROR) 
return  ERROR) 

) 

do 

( 

label  »  codeCchainl.c.opl) 
fix (chain) } 

) 

while  (chain  *  label)) 
return  ltype) 

) 


■tl 

tl 

tl 

tl 

>»/ 
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/IIHHHIMHil  ••••MHHHMMMMHfHIHHHtHHHMMtMHKM*/ 

It  ♦/ 

It  xor.coap  *> 

It  *  ♦/ 

/nttttttttttttttttitttttttttttitiltttttttltttitttitttttttttttttttlttl 


lnt  xor_conp (nodal 
int  nodal 

( 

RES  next, ltyp«| 

if  ((ltypa  *  relationfnext  ■  son (node) ) )  **  ERROR)  It  (relation)  tl 
raturn  ERROR) 
if  (ltypa  !■  TYPE.BOOL) 
if  <error(son<node),l>ool_exp)) 
raturn  ERROR! 

xhile  (!chk_flag(next,RTNOST))  It  {(xor_rel»  »/ 

if  (Ichk.f lag (next  ■  riqfit  (next ) ,  OPEN)  > 
if  ((ltypa  *  xor_rel (next) )  »«  ERROR) 
raturn  ERROR! 
raturn  ltypa! 

) 


/IHIIHHWinHWMHHMHIiillHMHHfliHHHHMIHHMIHH/ 
It  tl 


It 

relation 

tl 

It 

litttt 

IIHWMHHH 

tl 

int  relation(noda) 
int  nodal 

( 

RES  next,ltypefrtype| 

if  ((ltypa  •  s.explnext  ■  ion (node) ) )  ■■  ERROR)  /*  <s,expreasion>  *1 
raturn  ERROR! 

if  (!ehk_flag(next,RTHOST)  U  !chk_flag(next  ■  right (next), OPEN)) 

{ 

if  ((rtype  ■  rel.part(next))  ■■  ERROR)  It  [(relation .part))  *1 

raturn  ERROR! 
if  (ltypa  !»  rtype) 

( 

if  (error (next, ‘typee  auat  aatch')) 
raturn  ERROR! 

> 

alia 

raturn  TYPE.BOOll 

) 

raturn  ltypa! 

) 
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/iiiOtHHHOHIHliHtiHHtHliHHHHHHttHHtitHHIItHHH/ 


/♦  */ 

/»  naae  */ 

/♦  ♦/ 

/ ******************************************************************* */ 


int  nut  (node) 
int  node) 

( 


return  old.ident(son(node))| 

) 

/♦  (old)  (identifier) 

4/ 

/♦ 

#/ 

/*  loop.stat 

4/ 

/» 

44444444444444444444444444444441 

♦/ 

>444/ 

int  loop.itetlnodel 
int  node) 

( 

RES  next  I 

int  laball,label2|  /•  label  iddrtti  storage  *1 

label  1  «  gen <_LAB, 0,0,0);  /•  start  of  loop  */ 

label 2  •  *1| 

it  Inode.typelnext  *  son (node) )  *■  1  CLAUSE  )  ( 
it  ( !chk_f lag(nextf OPEN) )  ( 

if  (i.clauie(next)  ■■  ERROR)  /»  ((iteration.dause)]  ♦/ 

rat urn  ERROR) 

1 abel 2  *  gen(.JPC, 0,0,0))  /•  juap  to  exit  loop  *1 

) 

next  •  right (next) I 
) 

if  (seq.of_stets(next)  ■»  ERROR)  /«  (seq.of .stats)  */ 

return  ERROR) 

gen(.4NP,labell,0,0)|  /*  juap  to  loop  start  *1 

if  (label 2  !»  -1) 

fix(label2))  /*  fix  juap  to  exit  loop  *1 

return  SUCCESS) 

) 


APPENDIX  F 


It  tl 

/•  if.stat  *1 

It  i  / 


int  if.statlnede) 


int 

( 

RES 

node) 

next) 

int 

label  1,1 abel 2, chain, 
type) 

It  label  address  storage  *1 

if  ((type  *  exp (next  *  son ( node) ) )  »«  ERROR)  I*  (expression)  t / 

return  ERROR; 
if  (type  !»  TYPEJOOL) 
if  (error(next,bool_exp)> 
return  ERROR) 

label  1  *  gen(jlPC, 0,0,0);  /*  juep  to  else  */ 

if  (seq_of_stets(next  ■  right  (next)  1  «■  ERROR)  /*  <seq_of_stets>  ♦/ 

return  ERROR) 

chain  =■  label2  «  genl.JHP, 0,0,0))  It  juep  past  if _stet  *1 

while  <!chk_flag(next,RTNOST)  U  node_type(right (next) )  ■*  ELSIF.PJ 
if  ( !chk_f  legtnext  ■  right  (next) ,  OPEN) )  <  /*  «elsif _part»  */ 

fix(labell))  It  fix  juep  to  else  */ 

if  ( (label  1  ■  elsif .part (next))  *«  ERROR) 
return  ERROR) 

It  chain  locations  of  juep-past-if.stet  instructions  *1 
1 abel 2  •  code[label21.c  opl  »  gen <  JRP, 0,0,0)) 

) 

fix (label  1 ) I 

if  < !chk_f 1 ag (next, RTH0ST) ) 
if  ( !chk_f lag (next  ■  right (next) ,0PEN) ) 
if  lelse.part(next)  ■■  ERROR)  /»  [(else.partM  »/ 

return  ERROR; 
do  ( 

1 abel 2  ■  codeCchainhc.opl) 

fix (chain) )  It  fix  jueps-past-if.stet  */ 

)  white  (chain  >  label2); 
return  SUCCESS) 

} 
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(include  "adal.h* 


/*  »/ 

/*  proc.call  */ 

/»  #/ 

/HHIHHHHHHIlHIIHIitlHIHIWIHHIHflHiHMHWtHHt/ 


int  proc.call (node) 
int  node) 

{ 

REG  next; 

int  syel  /»  syebol  table  index  *1 

if  l  (sye  *  naee(next  »  son (node)))  ■»  ERROR)  /*  <naee>  */ 

return  ERROR; 

if  (syeboltsyel.sye.flaqs  U  TYPE_PR0C)  /•  suit  be  procedure  naee  */ 
if  (error (next, 'oust  be  procedure  naee1)) 
return  ERROR; 
else 

return  SUCCESS; 

gen  (_CAL,  1  evel-syebol  (sye) .  sye.level ,  syebol  (sye) .  sye_addr ,  next )  | 
return  SUCCESS; 

) 


/•HHMeeeeeeeeeeteteeeeeeeeteteeeeeteefteeeetfeeeeeeeeeeeeemee/ 
I *  */ 

/»  ident(ifier)s  ♦/ 

/«  t/ 

/tHtmmMfstmmmttfHmemtstttmttmmttsmimm/ 


int  idents(node) 
int  node; 

( 

return  nee.i dent (son (node)))  /<  (nee)  <identi *1 

) 
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1 


/HIHIHIIHiiHHHHtHitHHHHHHHHKtiHtKItttiiHHtitl/ 


/* 

♦/ 

/♦ 

a(ssiqnaent).stat 

*1 

/* 

*1 

int  a.stat(node) 


int 

node) 

RES 

next; 

int 

»Y». 

ltype, rtype) 

1*  syabol  table  index 

*/ 

if  ( (sya  *  naeelnext  ■  son (node) ) )  •«  ERROR)  /•  <ntaa>  ♦/ 
raturn  ERROR; 

if  ( ! < syabol 1 sya ] . sya.f 1 aqs  U  TYPE.VAR) )  I*  auit  be  VAR  #/ 

if  (error (next, ‘auat  be  variable  naae*)) 
return  ERROR; 

if  (Msyabollsyal.sya.flags  U  TYPE. CONST)) 
if  (syabol [syal.sya.fi aqs  U  TYPE.INIT) 
if  (error (next, "constant  initialization  allowed  only  once*)) 
return  ERROR; 

ltype  •  syaboltsyal.sya.typej 

if  ( (rtype  *  exp(right(next)))  ■*  ERROR)  /»  (expression)  •/ 

return  ERROR; 
if  (ltype  !■  rtype) 
if  (error (node, 'types  aust  aatch'H 
return  ERROR) 

gen ( .STO, level -syabol I sya] . sya. I evel , syaboli sya J . sya.addr , son ( node) ) ( 
return  SUCCESS) 

) 
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/#  »/ 

/«  exp(ression)  »/ 

/*  */ 


int  exp  (node) 
int  node) 

{ 

RES  next) 

if  < ! (next  *  son <nod«) >  > 
if  (error (node, noson) I 
return  ERROR) 

else 

return  SUCCESS) 


switch  (node  type(next))  ( 
case  RELATION.: 


return  relation(next)) 
case  AND.CONP.: 

/ t  (relation)  */ 

return  and.coeptnext)) 
case  OR.COHPJ 

/»  (and.coep)  •/ 

return  or_coep(next)| 
case  AND.THEN.CONP.: 

/•  (or.coep)  */ 

return  and.then.coep(next)) 
case  OR.ELSE.COHP.: 

1*  (and. then. coep>  »/ 

return  or.else.caeplnextM 
case  I0R.C0NP.: 

/*  (or.else.coep>  ♦/ 

return  xor_caep(next)| 

/#  (xor.coep)  */ 

) 
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/♦  sub<typt).ind(ication)  #/ 

/§  •/ 
/tmstmmtmmmmtttmtftmmmtmmtttttwsmm/ 

int  sub.lnd(nodt) 
int  nodi I 

{ 

int  ntxt,sya} 


if  (Mnixt  •  son  (nod*) )  > 
if  <trror<nodt,noton>) 
rtturn  ERROR} 

die 

rtturn  TYPE.INT} 

snitch  (nodt  typt(mxt)) 

{ 

cast  INTEGER,: 

rtturn  TYPE  INT} 
can  BOOLEAN.:' 

rtturn  TYPE .BOOL) 
cast  CHAR.: 

rtturn  TYPE  CHARI 
cast  I DENT.:  ' 
syt  »  old.idtnt(nixt)} 
if  (KsyabolCtyal.sya.flags  U  TYPE.TYPE) ) 
if  (trrarlntxVtypt  naat  txptcttd*)) 
rtturn  ERROR} 
tlst 

rtturn  TYPE  INTI 

tlst 

rtturn  syaboHsyal.sya  typt} 

) 

) 
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. . . 

/*  */ 
/'♦  s(ieple)_stet  tl 

/»  "  tf 

/eeeeeeeteeeestetaeeeseeeeteeeeeteeeeeteeefeteasseesttteeeeeeeeeee/ 


int  s_stet(node) 
int  nodtl 

{ 

REG  nut  | 

if  ( ! (next  *  ton (nod*))) 
if  (trror(nodt,no*on)l 
return  ERROR) 

else 

return  SUCCESS) 

SNitch  (node  typefnext) )  ( 
case  fl.STHT.: 

return  a_stat(next)|  It  (assigneent  stat)  #/ 

caw  P.CALL.: 

return  proc  call (next))  /t  <proc  call)  «/ 

case  IF.STHTJ 

return  if _stat (next) I  It  <if  *tat>  */ 

case  LP_STMT_: 

return  loop.stat(next)|  It  (loop  stat)  tl 

case  RET.STRT.  : 

return  ret  stat(next)) 
cate  COIMENT.  : 
case  MULL_STMT_  ! 
break) 

) 

) 

Ittttittttttittttttttitttttttitttitttiittitttitttttttttttttttttittl 


It 

tl 

It 

initial 

tl 

It 

tl 

/eeeeteeeeeeeeeeeteeeseeeeeeeeeeeeeeeteeteteeeeeeeeeeeeeeeeeeeeett/ 

int  initial (node) 
int  nodtl 

{ 

return  up  (son  (node)))  /t  (expression)  tl 

} 
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/tHtmmtmmtmtmtftmmKtmmtitmmtmtmmtttt/ 
/*  */ 

/»  obj(ect)_ded  »/ 

/*  »/ 


int  obi  decl(node) 

int 

( 

RES 

node) 

next; 

int 

stype, 

1*  type  of  variables  declared 

«/ 

type, 

/*  syabol  table  flags 

*/ 

strt; 

/*  first  syabol  table  entry 

«/ 

»trt  «  sya.ptr  ♦  1| 

if  (id.listfnext  *  son(node))  ■■  ERROR)  /»  (id.list)  •/ 

return  ERROR; 
type  !»  TYPE.VARj 

if  (node.typeinext  ■  right  (next) )  «■  CONST.)  {  /*  [‘constant']  */ 

if  l!ciik_flag<next,OP£N)) 
type  )■  TYPE. CONST; 
next  «  right(n»xt)( 

) 

if  ((stype  *  obj.type(next))  ■■  ERROR)  /•  <objtct.typi>  ♦/ 

return  ERROR) 

if  <!chfc_flag<n«xt,R7»0ST>  U  'chk.flagtotxi  «  right  (next)  .OPEN))  ( 
if  (initial (next)  *»  ERROR)  /»  ((initial)]  »/ 

return  ERROR! 

else 

type  l«  TYPE.INITJ 

) 

else 

( 

gen(_LIT,0,0.next)|  /<  no  initialization,  use  0  */ 

) 

syebolCstrtl.sya.type  •  stypei  /*  set  each  sysbol  type  */ 

syabol (strtl.sya.f lags  i»  type!  I*  set  flags  for  syabol  »/ 

while  (♦♦strt  <■  sya.ptr)  ( 
syabol (strtl.sya.type  *  stype! 
syaboUstrtl.sya.flags  I*  type) 

geni  CPY, 0.0, syabol ( strt l.sya  node);  /»  copy  initial  for  each  */ 
) 

return  SUCCESS; 

) 
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/•  */ 

/*  saq.of.stati  */ 

/*  «/ 


int  »aq_of_itnt*(noda) 
int  nodal 

{ 

REG  next) 


if  (atatlnaxt  «  wninoda))  “  ERROR) 
raturn  ERROR) 

/*  <*tat> 

*/ 

ubila  (!chk_fliq(naxt,RTNOST)) 
if  (!chk.flag(naxt  *  right (naxt), OPEN) ) 

/»  «itat» 

#/ 

if  (stat (naxtl  ERROR) 


raturn  ERROR! 
raturn  SUCCESS) 

) 


/a 

H 

J* 

prog(ru).coaplonant) 

»/ 

/* 

•/ 

/tmattaaaataamtaaamtaaaattaatatatttftMtmtamamtatwam/ 

int  prog.coap(noda) 
int  nodal 

( 

int  naxtl 

if  (!(naxt  ■  ton(noda))) 
if  (arrorlnoda^oaon)) 
raturn  ERROR) 

alsa 

raturn  SUCCESS) 
auitch  <noda_type(next)) 

{ 

caw  P.BOOY.  : 

raturn  proc.body(naxt)l 
caia  F.BOOY.  : 

raturn  func.body(naxt)) 


) 


) 
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/»  ♦/ 

/*  did  */ 

/•  »/ 

/IHIHHIHtHIHHHtHtlllitHItlHIHIHHHHtHHHHiHHHi/ 


int  dtd(nodt) 
lot  node! 

{ 

rtturn  obj  dtd(ion(nodt))| 
} 


/  HIHHiKHIHHiHHWMHHHHIttHIHHiHIHWHItlHHH/ 
/*  •/ 

/»  proc.iptc  */ 

/*  t  / 

/m#*»##tttt#t*ttt»#M**tmtttt*t**tt*tt»  tttttmtttttmmtm/ 


int  prx.nptc (nodt) 
int  nodt) 

{ 

RES  tyai  /•  tynbol  tibln  indnx  •/ 

if  ((syn  ■  nw.idtnt  (ton  (nodt)))  ERROR)  /*  nm  <idmtifitr>  */ 
rtturn  ERROR) 

tynboUiynl.iyt.typt  !*  TYPE.PR0C)  /»  stt  tynbol  typt  •/ 

rtturn  iyn{ 

} 


/tMttmtttttttttttmtttttttttttftttmMftttmttmtMttmttt/ 
/*  */ 

/*  coapdlntionl.unit  */ 

/*  */ 

/WHHHIHIHMIMMHHHHIHtiHtlHHItltlHmMHHtlHH/ 


conp.unit(nodt) 
int  nodt) 

{ 

int  nnt) 

if  (Hntxt  *  son(nodt))) 
if  (trror(nodt,noion)) 
rtturn  ERROR) 
tlu 

rtturn  SUCCESS) 

Mitch  (nodt.typt(ntit)) 

{ 

cim  P.SOOY  : 

rtturn  proc.bodylntit)) 

cim  f.sody  : 

rtturn  func.body(nttt)) 
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} 

1 


It  */ 

/«  prx.body  tl 

/»  */ 


infc  prx.body  Inode) 


int 

node; 

RES 

next; 

It  thru  sibling  list 

tl 

int 

label, 

It  label  reiolution 

tl 

ent, 

It  nuaber  of  variable*  declared  *1 

It  lyebol  entry  1  of  proc  naee 

tl 

if 

if  (nod*_typ*(next  ■  ion (nod*))  ■*  PR0G_HDRJ 
next  *  right (next); 

if  ((>y*  *  proc.ipec(naxt))  ■»  ERROR)  It  (prx.ipec)  ♦/ 

return  ERROR; 

iy*boltiyi].iy*_iddr  •  g»n(_LAB, 0,0,0);  It  proc  *ntry  addrett  •/ 

♦♦level;  It  bu*p  lexical  level  */ 

offiet  »  0|  It  xero  level  offiet  »/ 

•hi  1»  (nod*  typ*(n*xt  *  right(next))  **  DECl  )  /»  Kdecl»  *1 

if  <!chk_flag(n*xt,QPEN)) 
if  (ded  (next)  •«  ERROR) 
return  ERROR) 
ent  *  offietf 
offiet  ■  0; 

label  ■  genf.JKP, 0,0,0))  It  juep  around  procedure*  ♦/ 

•hi le  (node.type(next)  ■*  P_C0HP.)  (  /»  Kprogra*,coepon*nt»  a/ 

if  ( !chk_41ag(nextf OPEN) ) 
if  (prog.coep(next)  *»  ERROR) 
return  ERROR; 
next  ■  right (next); 

1 

fix (label) |  /•  fix  juep  around  procedure!  «/ 

body.type  -  TYPE.PRQC) 
ret.lst  •  0; 

if  <s*g.of.et«ti<n*it)  “  ERROR)  It  <i*g.of.itati>  */ 

return  ERROR) 

if  (!chk.fleg<n«t,RTN08T)  II  Ichk.f lag (next  ■  right  (next), OPEN))  { 
if  ((i  ■  old_id*nt(n*xt))  ■■  ERROR)  /*  ((identifier)]  tl 
return  ERROR I 
if  (i  !*  lye) 

if  (error (next, 'procedure  id’s  do  not  Bitch’)) 
return  ERROR)  It  euit  ■*  first  identifier  */ 

) 
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if  (ret.let) 
do 
< 

i  *  codeCret  lftl.c  opli 
fit (rot  lot)] 

>  «hile(ret.l*t  ■  i)( 

gen(.DCS,cnt,0,node))  /*  rooovt  virioble  itock  tpocc  */ 

—level)  /*  roitorc  lexical  ltvcl  */ 

xbile  <»yebolt*ye_ptr).iyeJevel  >  level )  /•  pool  eyebol  table  »/ 

eyebol  t*ye_ptr— l.$ye_flig»  ■  01  /*  door  flege  field.  »/ 

/*  loovo  procedure  nooo.  •/ 
gen (.RET, 0,0, node) I  /•  return  froe  procedure  */ 

return  SUCCESS) 

} 
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(include  'adal.h' 


/*  »/ 

/*  goal  */ 

/»  <coepilation>  is  ADAQ  language  ;ruur  goal  sytbol.  »/ 

/»  »/ 


int  goal (node) 
int  node) 

{ 

noson  *  'incosplete  proqras  frageent*) 
bool.exp  *  'boolean  type  expected'! 
i nt_exp  1  'integer  type  expected') 

typesMUl  1  *  '♦'! 

typesIPLUS.J  *  '♦') 

typeslHINUS  1  =  '-') 

typesCDIV.l  «  '/') 

typesINEOJ  *  '/*') 

typeslLES  ]  *  *<  ') 

typesILEflj  •  '<*'! 

typestEQU.]  »  '«') 

typesIBRT.]  •  •>  ') 

typesIBEQJ  »  *>■') 

types! A.STRT.l  *  'assigneent.itet*) 

typesIAND.CONP.]*  'and.cotp'l 

types [CONST.]  *  'constant'; 

typesIDEC.NUH.]  *  'decieal.nueber'5 

typesfDECL.]  *  'ded'l  ' 

types!ELSIF_P_]  *  'elsifjart*! 

types! IF.STHT.]  «  'if.stet'; 

types! 1. CLAUSE.]*  'iteration.clause') 

typesCLP.STNT.j  *  'loop.stst'5 

typestNAHE.]  *  'nase'l 

typesIN.EIP.)  *  'nested.exp*! 

typesIQR.CQliPJ  »  'or.coep'J 

typesIP.CALL.i  «  'proc.call'J 

typesCP.COHP.]  *  'progras.cosponent'l 

typesCRELATION.]*  'relation'! 

typesCU.OPJ  •  'unary.operator'l 

typestREH.]  *  'res'!' 

typesINOD.J  •  *sod‘! 

typestAND.THEN.COHP.]  ■  'and.then.coep') 
typestOR.ELSE.CONPJ  *  'or.else.coep') 

types!  XOR.CONM  *  'xor.coep'J 

types! INTEGER.]  «  'integer'! 

types!BOOLEAN*J  •  'boolean') 

typestCHAR.LIT.l  ■  'char.lit'J 

typestIDENT.]  *  »  'identifier') 

types! TRUE  *]  •  'true'! 
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typestFALSEJ  »  ‘Ulse'f 

typesCF.CALLJ  ■  Munc.cill'i 

typeiIF*IODY j  «  •func.body"} 

typ**£P_80DY_3  *  *proc_body*J 

typ»*CRET_STHT_l  »  ,rrturi».*tit,t 

typcvCBOOLEAM _VALUE_3  ■  'booldn.vaiui'; 
typ*s£EXP_PRli««Y_3  -  ■wp.priMryM 

typ»£ ABS.PR IRARY. 3  «  'abP.priMry*! 

typ»»tWT*PRI«WY  J  »  *not.priMry*J 
typdlEIPW.PART.]  •  ,«»pon.pirf  t 

typMtCHAR.i  «  'chir’l 

typ«iIPRQC_RETJ  «  ,prpc»dur«.r«turft,l 

typtsIFUAC.RETJ  »  *function.rtturn,| 

typtiCCOIfflENT.i  »  ‘caiunt'l 

typf sENULL_STHT_]  «  ,null.it«t,J 

typMlPROfi.HOR  .1  ■  ,pro9ri«.heider,l 

typesELAST ~PR0D_3  «  Oi 
fill.typisOi 

r*turn  co«p_unit(*an(nod*))i  /♦  <co*pilation_unit> 

) 
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♦include  ‘adal.h" 

/IHHHHilHHOiftHIKtiHititimHtHiilHKHmUHliHHHtl/ 


/♦  */ 
/♦  func.body  *1 

/♦  ’  */ 

/IHHIHiltHHIlHWHfHitHIHHilttHiHmtHmiiHHHHHIH/ 


int  func .body (node) 

int 

{ 

RE8 

node) 

next) 

/*  thru  sibling  list 

♦/ 

int 

label, 

/♦  label  resolution 

♦/ 

ent, 

/*  nueber  of  variables  declared  ♦/ 

sye, 

1 *  syebol  entry  t  of  func  naae 

#/ 

il 

if  (node.tvpelnext  *  son (nod*) )  **  PROB.HDRJ 
next  *  right (next) ; 

if  l  (sye  «  func.spec(next))  ■»  ERROR)  /»  <func_spec>  */ 
return  ERROR; 

syabollsyal.sye.addr  *  gen (.LAB, 0,0,0);  I*  func  entry  address  */ 

♦♦level;  /»  buip  lexical  level  ♦/ 

offset  »  0;  /»  aero  level  offset  */ 

while  (node.typ*(n*xt  »  right  (next))  «•  DECL_)  /♦  «ded»  «/ 

if  <!chk.flag(next,OPEN)> 
if  (dad (next)  ««  ERROR) 
return  ERROR; 
ent  *  offset! 
offset  «  0J 

label  ■  gent.JNP, 0,0,0);  I*  juep  around  functions  ♦/ 

while  (node  typelnext)  *»  P  COUP  )  I*  Kprograe  coeponent))  */ 

( 

if  (!chk.flag(next,0PEN)) 
if  (prog.coap(next)  ••  ERROR) 
return  ERROR; 
next  •  right(next); 

) 

fix (label ) |  /*  fix  juep  around  functions  ♦/ 

body.type  *  TYPE.FUNC;  /♦  indicate  working  on  function*/ 

ret.type  *  syebollsyel.sye.type)  /*  indicate  return  type  »/ 

ret.lst  *  01 

if  (seqj>f.stetstnext)  «■  ERROR)  /t  (seq.of.stets)  »/ 

return  ERROR; 

if  (!chk  f lag (next, RTIWST)  U  !chk  flagtnext  *  right (next), OPEN)) 

( 

if  ( (i  ■  old.identlnext  ■  son (next)))  ■■  ERROR) 
return  ERROR! 
if  (i  !■  sye) 

if  (error (next, 'function  designators  do  not  Batch')) 
return  ERROR;  /«  eust  •»  first  identifier  ♦/ 

) 
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if  (ret.lst)  /«  check  if  return  list  exists  */ 

do 
{ 

i  *  codeCret _1 st ] . c_opl { 
fix  <ret_lst) I 
)  while  (ret.lst  *  i)) 
else 

if  (error (node, ‘functions  aust  contain  a  return  stateaent*)) 
return  ERROftf 


geni.STO, 0,-4, node);  /*  save  return  value  *1 

gen(J)CS,cnt,0,node);  /*  reaove  variable  stack  space  */ 

--level)  /♦  restore  lexical  level  »/ 

while  (syaboltsya_ptr].sya, level  >  level)  /*  reset  syabol  table  */ 
--syejtr)  /•  leaving  function  naae  ♦/ 

gen (.RET, 0,0, node))  /•  return  froa  function  »/ 

return  SUCCESS) 

) 

/imtsttmtmemtamttammmttmafmmfHtmmtmmtt/ 
/♦  «/ 

/»  function.specification  »/ 

/*  *  t/ 


int  func. spec (node) 
int  node; 


{ 

RES  next,sya| 

if  ((sya  *  desig (next  3  son (node) > )  *«  ERROR) 
return  ERROR! 

syabollsyal.sya.flags  !■  TYPE.FUNC) 
if  ((syabollsyel.sya.type  *  sub.ind(right(next)))  *■  ERROR) 
return  ERROR) 
return  sya) 

) 
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/* 

i/ 

/»  function  call 

»/ 

/» 

*/ 

int  func_cali (node) 

int  node) 

{ 

int  next, sya( 

if  Msya  *  old_ident  <next  *  son  (son  <node) ) ) )  **  ERROR) 
return  ERROR) 

if  (! (syabolleyal.sya.flaq*  it  TYPE.FUNC)) 

<  error (next, 'function  naae  expected*); 
return  ERROR; 

} 

gen(J.IT, 0,0, node)!  I*  create  space  for  return  ♦/ 

/*  value  */ 

gen (.CAL, level -syeboU  syal . sya.level , syabol Csya] . sya.addr ,next ) ; 
return  lyabollsyel.sye.typei 

> 


/* 

»/ 

/*  deaiqnator 

*/ 

/* 

»/ 

int  desig(node) 
int  nodel 

( 

return  (ncM.ident (son(node)  1 ) I 

) 
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/*t**«t****ttmtm*«**tttt**t*tt**t***Ht*t**t<**t*tmtmtmtttt/ 
/»  »/ 
/»  return.stateeent  •/ 
/«  *  »/ 


int  ret.stet(node) 
int  nodi} 

( 

RES  nnt} 

if  (! (next  ■  ion (nod*) ) ) 

{ 

error(nodi,noson){ 
return  ERROR} 

} 

snitch  (nodi  type (next)) 

( 

can  PROC.RET.  ! 

return  proc .ret (next)} 
cue  FUNC.RET.  f 

return  func  ret (next)} 

> 

) 


/♦  1/ 
/»  procedure.return  -  iccept  a  procedure  return.  */ 
/*  *  */ 

/mtemtmememmmMffemtmmmmettfmmetmtmit/ 


int  proc.ret(node) 
int  node} 


if  Ibody.type  ««  TYPE .FUNC) 
if  (error (node, 'functions  eust  return  *  value' )) 
return  ERROR} 

else 

qen(.LIT, 0,0, node)} 

ret.lst  »  gen(.JNP,ret.lit,0,node)| 
return  SUCCESS} 

) 
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/iHHHHItHWHIHHHHitlHIKtlHHtlHtlHHItltHHIlittHII/ 


/*  ♦/ 

/»  function .return  -  accept  a  function  return.  */ 
/*  it  eust  return  the  correct  type,  return  type  * / 
/*  it  stored  globally  in  ret.type.  */ 
/»  ’  «/ 


/feeeteeHefeefeeteeeieeeeeteeiaetifeatiaifataaaeaeaeeateeeiieeiteeea/ 

int  func .ret (node) 
int  node! 


( 

int  type, next! 

if  (body. type  *«  TYPE.PRQC) 
if  (error (node, 'procedures  cannot  return  a  value')) 
return  ERROR; 
else 
( 

ret.lst  »  gent.JNP, ret. lst,0, node); 
return  SUCCESS; 

} 

if  ((type  ■  exp (next  ■  ton (node)))  ■*  ERROR) 
return  ERROR; 
if  (type  !•  ret. type) 

if  (error (next, 'return  expression  of  Mrong  type')) 
return  ERROR; 

ret.lst  •  genl.JMP, ret.lst, 0, node); 
return  SUCCESS; 

} 
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(include  ‘adal.h1 


/*  t/ 
It  exponent  priaary  -  accept  a  priiary  with  an  optional  tl 
It  exponent,  it  the  exponent  exists  it  euit  be  t / 
It  an  integer  and  poiitive.  tl 

It  1 1 
/titttttttttttt*ut*it*tttttttttttttt*§nmnmtitn*ttttiittnntil 


int  exp.prie(node) 
int  node) 


{ 

int  typcl , type2, next; 

typel  *  priearytnext  3  son  inode) >  • 
if  (node.type(next  *  right (next ) )  !*  ETPQN.PART.) 

return  typel; 
if  (typel  !*  TYPE.INT) 
if (  error (next, int.exp)) 
return  ERROR) 

if  (expon_part(next)  !■  TYPE.INT) 
if  (error (next, int.exp)) 
return  ERROR) 
gen(_E*P, 0,0, node)) 
return  typel) 

1 

/*eefetee*etHfH*t*e«eet**t»e*»***ti**«i*t*t«ttit*tett«ft«ttte*tt«te/ 
It  tl 

It  exponent  part  -  accept  the  exponent  part  of  a  factor  tl 

It  generate  code  to  do  exponentiation.  Exponent  tl 

It  aust  be  of  type  integer,  */ 

It  tl 

int  expon .part (node) 
int  node) 


( 

return  priaary(ton(nodel)i 

1 
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/♦  */ 

/»  abs  priaary  -  accept  an  absolute  value  priaary.  */ 

/*  generate  code  to  find  the  absolute  value  a/ 

/♦  of  its  argueaent.  »/ 

/*  */ 

/•eeeeeeeeeeeeeeeeeeeeteteeeHteeHeeeeeHeeeeeteaeeeeaeeeeaeeeteeee  a/ 


int  abs.pria(node) 
int  nodal 


int  next, type! 

if  ((type  •  priaary (next  •  son (node) ) )  !■  TYPE. INT) 
if  (error (next, int. exp)) 
return  ERROR) 
gent.ABS, 0,0, node)) 
return  typel 

} 


/ttttfttteatmmmttttttftttftfmafttattmatmmmaatffmm/ 
/♦  »/ 
/*  not  priaary  *  accept  a  negated  boolean  priaary.  */ 
/»  its  argueaent  aust  be  a  boolean  expression.  (/ 

/»  */ 


/»at*a*s«a»«»i*t*aa*e4***«*f*at***a««*ff***t«tft«at******eet«eettt**t/ 

int  not.pria(node) 
int  nodel 


( 

int  type, next! 

if  ((type  ■  priaary(next  «  son(node)))  !»  TYPE.B001) 
if  (error(next,bool.exp)) 
return  ERRTOl 
gen(.N0T,0,0,node)| 
return  typel 

) 
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/MIHWMmMHHmHIHHMMHIMOMimiHMHHWIMHMIMMHH/ 
/«  00000  00  00  00  00  00000  00000  ♦/ 
/*  00  00  00  000  00  00  00  00  */ 
/#  00000  0000  00  0  00  00  00  0000  »/ 
/»  00  00  00  000  00  00  00  ♦/ 
/*  00000  00  00  00  00000  00000  */ 
/•  ♦/ 
/»  SYNtax-Directed  Editor  (c)  Copyright  December  1982  */ 
/*  CAPT.  Scott  Eduard  Ferguson,  USAF,  AF1T  GCS-82D  «/ 
/*  Modified  October  1983  ♦/ 
/*  CAPT.  Michael  L.  McCracken,  USAF,  AFIT  6CS-83D  ♦/ 
/♦  */ 
/t  IMTERP.C  ♦/ 
/*  SYNOE  lyitea  ‘dynaaic  display*  interpreter.  The  interpreter  «/ 
/*  itself  is  language  independent,  using  a  stack  pseudo-aachine,  «/ 
/♦  but  aust  be  linked  with  language  dependent  coapiler  routines.  *1 
/mmtfttftmttittmmtmmtMtttmftftttttmttttmtttmtmtt/ 


(include  'synde.h*  /•  systea  global  inforaation  structures  */ 
(include  'types. h*  /♦  production  type  definitions  */ 
(include  'code.h*  /♦  pseudo-code  structures  */ 
(include  <curses.h> 


extern 

/*  source  file  inforaation 

♦/ 

struct 

file_info  src.infol 

/♦  in  AST.C 

♦/ 

extern 

/♦  tsrainal  display  inforaation  ♦/ 

struct 

tera.info  tdf.dataj 

/♦  in  DISPLAY. C 

♦/ 

extern 

struct 

codeword  *code) 

/♦  pseudo-code  aeaory 

♦/ 

extern 

/«  in  EXECUTE. C 

♦/ 

int 

inst.ptr, 

1*  instruction  pointer 

♦/ 

stkjitr, 

/*  stack  pointer 

♦stack f 

/♦  stack  space 

♦/ 

char 

♦codesl.MOOPl, 

♦typeslLAST.PROD.l, 

/♦  instruction  naaes 

♦/ 

♦noson, tint  exp, »bool .exp, 
str CHIDE3I 

/*  display  line  to  build 

♦/ 

int 

chi 

/♦  coaaand  input  character 

♦/ 
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/♦  aain  </ 

/*  Entry  point  and  driver  for  interpreter.  ♦/ 

/Mteeeeateettftfeetseetatetaasteetteeetetsettaeeettseaeeetetttteaetetete/ 

aain(argc,argv) 

int  argci  /«  input  argument  count  ♦/ 

char  eargvtlj  /»  input  arguunt  ptrs  *1 

{ 

puts I ’INTERPRETER  11/11/83  ’>! 

if  large  <  2)  <  /*  prepare  tource  file  naae  */ 

putsl’Unspecified  source  file.  '); 
exit  Of 
} 


/*  initialize  »/ 

if  (ajnitlargvlll)  «  ERROR  !!  s_initlsrc.info.Mang>  «  ERROR) 
exit!); 

if  IcoapileO)  {  /*  check  generated  code  for  errors  *1 

puts (’Errors  in  source  prograa.  Continue  with  interpreter?'); 
if  (toupper(getcharO)  *■  ’Y’) 

interpret!)!  /«  interpret  oseudo-code  any  nay  */ 

) 

else 

interpret!)!  It  no  errors,  interpret  pseudo-coda  */ 

if  (a.NrapO  «  ERROR) 
exit!)! 
s.urapOl 

if  (src_info.f_edit)  { 

exKl  I  ’synda* ,  'synde* ,  argvl  13,2); 
putsl'Cannot  access  SYNDE.  *); 

) 

1 
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/HIIHHIHHHHHHHHIHHIHHIUHIIHHHHHHMMHMIHHMMI/ 

I »  interpret  •/ 

/*  Interpret  th«  generited  code  Kith  dynaaic  diipliy  of  *1 

/*  prograe  AST  tru.  Allow  user  interaction  to  execute,  1/ 

I*  single-step  and  terelnate  execution.  «/ 

interpret!) 

! 

int  focus?  /a  diilay  iaige  focus  */ 

BOOL  contl  /♦  continue  exKution  »/ 

codest.JHP]  ■  'JHP'f  /e  imtruction  ruses  */ 


codes! _CPY1  «  *CPV*t 

codes!  .STO)  *  *ST0*| 

codesl'cAU  «  'CALM 

codesC.JPC]  «  'JPC'J 

codesC.EQU]  «  'EQU*! 

codes! *NEQ]  »  ‘NEfl’) 

codes!  LEST  >  'LES'J 

codes!. LEB1  -  ‘LEB'I 

codes!  SAT]  *  *GRT'; 

codes!  6EB1  *  'GEB'J 

codesI.NESl  «  'NEB'! 

code*!. ADD)  *  ‘ADD*; 

codes!. SUB1  >  ’SUB*) 

codesC.NUU  »  'HUL'J 

codest.DIVl  «  *DIV*( 

codesI.LIT]  «  'LIT*) 

codes!  LOO)  »  ‘LOOM 

codes! .RET)  «  *RET*| 

codes!. AND]  >  'AND'! 

codes!.!*)  •  *0R'J 

codest.NOT)  «  'NOT'! 

codes!. DCS]  ■  'DCS'! 

codes!. NOD]  *  'NOD'! 

codes! .RER)  «  'REN'! 

codesC.AND.THEN]>  'AND.THEN'I 
codes! .OR.ELSEl  »  'OR.ELSE'I 

codes! _XORJ  «  'XOR'i 

codes!  ABS1  ■  'ABS'I 

codes!  EXP)  >  'EXP'! 

codes!  NOOP)  ■  'NOOP'i 
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systea  fstty  cbreak'li 
lyitea  (*stty  -echo*); 

if  (d.initl)  **  ERROR  i!  i  initO  «*  ERROR  !i  •  initO  ««  ERROR) 
exitOj 
focui  »  NIL; 
ch  ■  0) 
cant  ■  TRUE; 
ahile  (cant)  ( 

if  (focui  *  codeCinit.ptrhcjiode) 

»indo«<0, focus, TRUE) I 
do.rtfrnhOi 
ihoN.ittckO) 
ihou.initO; 
if  (ch  !«  ’O’) 

( 

image  ('Single-step,  Continue,  Restart  or  Exit?'); 
ch  *  toupper (keyinO ) ; 

Hinge  (“); 

> 

snitch  (ch)  { 

cue  ’C’:  image  ("is 
cue  ’ 
cm  'S’: 

if  (executed  ■■  ERROR) 

( 

■esitgeCEnd  of  valid  prograa.*); 
ch  *  0| 

) 

else 

break; 


case  ’R’: 

restartO;  break; 


} 

djripOj 

i.orapOt 

e.HrapOl 


cm 

cont  ■  FALSE; 

> 


systHCitty  Kho'i; 
syitMCitty  -cbreak'X 
) 
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/IHHIHHIHHHMMMHIHHHHIHMHHHHMHHMtMIHHHIHHM/ 

/»  shoe.stack  */ 

/*  Display  a  portion  of  thi  top  of  stack  on  the  tcrtan.  ♦/ 


shoa.stackO 

( 

REG  if 

strcpy (str, 'Stack:  *); 

for  (i  *  stk.ptr  *  If  i  >•  0  Mr  strlen(str)  <  tdf.data. chars)  — i)  { 
catnuafstr, itack£i 3) ! 
street (str, •  *1) 

> 

dsp.linelstr, tdf.data. lines  -  3)) 

} 


/IHIHHtHHWIHHIHHIHIMIHHHHimHmiHHIHfHMHHMm/ 
/*  shoe.inst  » / 

I*  Display  the  nest  instruction  to  be  esecuted  on  the  */ 

/ »  screen.  */ 


/tHHIHIHHIiHHHHMIlHMtHHHilHtHKMMHHHHHiHHHHH/ 

shON.instt) 

( 

RE6  i; 

strcpy (str , 'Next  instruction  la)| 
catnu»(itr,inst..»tr)| 
street (str,*: 

if  <(i  «  codelinst.ptrl.c.opcode)  >  0)  { 
street <str,codeslil)J 
street (str, •  ')) 

catnua (str , code! i nst .ptr ] . c.op 1 1 ; 

strcat(str, *,*!) 

catnua(str,codetlnst_ptr3.c_op2)) 

) 

else 

street (*tr , ■ INVALID*) I 
dsp  line(str,tdf.data.lines  -  2M 
) 


/*  instruction  aneaonic  */ 
I »  operand  1  */ 
/»  operand  2  *1 
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/IHmHHHtilMHHHHilHiHMHHtMHHttlHHtdHHtHiiHlillH/ 
/»  catnua  ♦/ 


It 

Concatenate  the  ASCII  representation  of  a  signed  nuaher  tl 

It 

to  the  end  of  the  given  string. 

tl 

catnuaistring. 

val) 

char 

int 

{ 

char 

•string} 
val } 

st7]| 

It  temporary  string 

tl 

RES 

if 

It  string  index 

tl 

if  (val  <  01  ( 

•treat (string, | 

It  negative  value 

tl 

val  * 

) 

•Ci  *  61  «  0} 

-vail 

It  generate  characters  in 

tl 

do  ( 

It  reverse  order 

tl 

st— i3 

*  val  X  10  ♦  ’0’| 

}  ahiie  tvtl  *  val  /  t0)f 

•treat  (string,  tisti  7)  ( 

It  concatenate  nuaher  string 

tl 

} 
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/HNliHtHittHIHHtitttittltiKttHmitHHHitlHItHHHKHttHI/ 


/» 

tl 

/I 

00000 

00  00  00  00  00000  00000 

tl 

it 

00 

00  00  000  00  00  00  00 

«/ 

It 

00000 

0000  00  0  00  00  00  0000 

♦/ 

It 

00 

00  00  000  00  00  00 

*/ 

/» 

00000 

00  00  00  00000  00000 

#/ 

/• 

*/ 

It 

SYNtax-Directed  Editor  <c)  Copyright  Deceaber  1982 

♦/ 

It 

CAPT.  Scott  Eduard  Ferguson,  USAF,  AFIT  SCS-82D 

♦/ 

/t 

Modified  October  1983 

*/ 

/♦ 

CAPT.  Michael  L.  McCracken,  USAF,  AFIT  6CS-83D 

♦/ 

/• 

♦/ 

it 

EXECUTE. C 

tl 

/* 

SYNDE  systea  pseudo-aachine  eaulator.  Stack  organization: 

tl 

/# 

tl 

/♦ 

...  <-  stack  pointer 

»/ 

/'I 

top  of  stack 

t  nark  space  3 

»/ 

/• 

a  a  a 

*/ 

/» 

[  local  variables  1 

t/ 

/« 

C  static  link  1  <-  base  pointer 

»/ 

/» 

[  dynaaic  link  1 

♦/ 

/t 

bottoa  of  stack 

C  return  address  1 

»/ 

/• 

tan 

t/ 

It 

»/ 

(include  'synde.h'  It  systea  global  inforaation  structures  */ 


lincluda  ’code.h* 

It  pseudo-aachine  structures 

tl 

extern 

struct  codeword  nodal 

/e  instruction  space 

tl 

•define  STACK  100 

It  stack  size 

tl 

int  instjitr, 

/•  prograa  instruction  pointer 

tl 

basejtr, 

It  base  pointer  register 

tl 

stk_ptr, 

It  stack  pointer  register 

tl 

•stack! 

It  eachine  stack 

tl 
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/*  *1 

i *  e.init  */ 

/»  Initialize  execution  emulator.  »/ 

/»  */ 

/HIHHIHKHHMHHtHItilOHtOiHHHKtHHHtltHHHHHdHH/ 

int  e  ini t  U 
( 

if  ( !  (stack  *  aalloc(STACK*2)))  /»  allocate  stack  space  «/ 

return  ERROR) 

restart!))  /»  set  processor  at  beginning  *1 

} 

/»  «/ 

/*  restart  */ 

/*  Set  the  execution  eeulator  to  resuee  at  prograa  start.  ♦/ 

I*  ♦/ 


/ttstsmatsstmssmtamaatmtamsmtttmmatmtmtmtstms*/ 


restart!) 

t 

stk.ptr  *  inst.ptr  »  0)  /♦  clear  stack,  inst  pointer  */ 

push (0) ;  /»  return  loc  for  function  »/ 

push (-1) ;  /*  *progra»  end'  return  addr  »/ 

push (0) |  /t  initial  dynaaic  link  t/ 

base.ptr  «  stkjitn  /*  base  pointer  to  static  link  *1 

push (0) ;  I*  initial  static  link  » / 

return  SUCCESS) 

) 

/*  */ 

/'•  execute  */ 

/»  Execute  the  next  aachine  instruction.  Return  ERROR  * I 

/♦  upon  reaching  end  of  prograa  or  invalid  instruction.  */ 

/«  ♦/ 


/aeeeeettettemmetmttmetmttmmttmtsmtmmtmmtamx/ 

int  execute!) 

< 

register 

struct  codejwrd  elnst/eg)  /»  pointer  to  current  inst  */ 

int  i|j|k,l) 

inst.reg  ■  lcodeIinst.ptr++3{  I*  fetch  next  instruction  * / 

suitch  (inst.reg-k.opcode)  !  I*  decode  instruction  »/ 

case  JHP: 

inst_ptr  *  inst_reg->c_opl»  break) 


184 


APPENDIX  F 


cast  _CPYs 

push (push (pop()))f  brisk} 
cast  _8T0S 

stackCbmUnst.ru-k.opn  ♦  1  ♦  inst_riq->c_op21  •  pop(M 
brtak} 

cast  CAL: 


push  Unit ,ptr)( 

/ t  savt  rtturn  addrtss 

«/ 

push (bast  jitr); 

/ 1 

dynaaic  link 

a/ 

push (bastiinst . rig- >c_opl 1)1 
bastjtr  ■  stk.ptr  -  1| 

/» 

static  link 

*1 

inst_ptr  ■  inst_rtg->e_op2| 

/»  victor  to  routint 

a/ 

brtakl 

cast  .JPC: 

if  (IpopOl 

inst_ptr  ■  inst.rtq->c_opl) 

brtak; 
cast  .EOU: 

push (pop 0  ••  pop 0 ) I  brtakf 
cast  .DEO: 

push  (pop  0  !■  pop 0)|  brtak; 

cast  _LES: 

i  *  popOl 
j  ■  popOj 
pushlj  <  ill 
brtakf 

cast  _LEB: 

i  *  popOl 
j  ■  pOpOt 
pushtj  <■  i)( 
brtak; 

cast  .MT: 

i  «  pop()| 

j  «  PSPOI 
ptsMj  >  i)| 
brtak; 

cast  _8£fl: 

i  a  popo; 

J  • 

pushtj  >•  ill 
brtakl 
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cut  .neb: 

puthl-popOH  break! 
cm  .MB: 

push  (popO  ♦  popO)!  break! 
cm  .81)8: 

i  •  popOl 
i  ■  popOl 
push(j-i)! 
break! 

cm  .RUt: 

push  (popO  •  pop 0 ) I  break! 

cm  .BIV: 

i  •  popO) 

push  (pop  ( )  /  1 )  I  brnkl 
cm  .LIT: 

pushdnst.rep-k.opl)!  break; 
cm  .LOB: 

push  (it  ack  (bn*  <  i nst .rep->c_op  1 )  ♦  1  ♦  inst_reg->c.op2])| 
brnkl 

cm  .RET: 

popOl  /•  discard  itatic  link  a/ 

ba«a.ptr  *  popOl  /•  restore  base_ptr  •/ 

if  ((inst.ptr  ■  popO)  ■«  -l)  /*  restore  instjtr  #/ 

return  ERRORl  /•  esit  if  "end*  #/ 

break; 
case  .ANB: 

push  (popO  kb  pop ( ) ) |  break! 
case  .OR: 

pusblpopO  II  popO) I  brook! 
case  .NOT: 

p«sh(!pop())|  break! 
case  .DCS: 

stijtr  -«  inst.rep->c.opi(  break! 

case  .REN: 

i  *  popOl 
j  •  popOl 

pesbtj  -  Kj/i)  •  DU 

break | 
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cut  .MB; 

i  •  popOl 

j  •  popOl 
14  <(k  ■  j/U  >•  0) 
puaMj  -  (k  *  ill) 

alia 

puthU  ♦  j  -  (k  a  i))| 
brnkl 


cm  .AM.TMQi: 

14  l.'popO) 

inat.ptr  «  inat.rap->G.opl| 
braakl 

cim  .M.ElSEi 

if  (popO) 

intt.ptr  *  inat .rap- >c .opt | 
brnkl 

cm  _J»: 

1  ■  pop()| 

J  *  P«P Of 

ptwMHIi  W  j)  *1  (!i  Ifc  !j)))| 

brnkl 

cm  .ABB: 

if  111  ■  pop!))  <  0) 
puihWH 
tin 
puiMilf 
brnkl 

can  .ElP: 

i  «  P«pO| 
if  (i  <  0) 

{ 

pataHEWOB  -  napativ*  aiponaat*)) 
ratura  ERBOBl 

) 

J  ■  PM»I 

1  ■  Jl 

farlk  ■  l|  k  <  if  k*l 
l  •  1  #  j| 

PMMDI 

brnkl 


cm  .MOP: 
brnkl 


kafaalt: 

J 
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raturn  SUCCESS) 
) 


/•  Puah  a  valua  onto  th*  atack.  Tha  puahad  valut  i*  aite  1/ 


/•  raturnad.  Stack  ovarfloM  aiiti  with  an  arror  aaaaaga.  »/ 

/*  a/ 


int  puaMval) 

iat  vail 

{ 

if  (atk.ptr  )«  STACK)  { 

put 1 ('Stack  ovarflo«.*)| 
•iltlll 
) 

raturn  atKkistk  ptr«*J  ■  vail 

> 


iat  pop!) 

t 

if  (itkjtr) 

raturn  itackt— atkjtrl) 

put* ('Stack  undarflou.')) 

aiitOi 

} 
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/tWHHIHHiMWHtHHHHtlimHHItHliKitHiHIIHIHIIHMHH/ 


/•  */ 
/*  biH  */ 

/*  R«turn  tha  baaa  pointer  for  tha  given  itatic  laval  a/ 
/a  difference.  a/ 
/a  a/ 


iat  baaa (laval) 

lot  laval) 

(  . 

RES  new.basei 

new.base  ■  base.ptr{  /a  start  with  current  basejttr  a/ 

while  (level)  ( 

new.base  «  stackvnaw.bm])  /*  chain  to  bast  pointer  at  tha  a/ 
—level)  /a  desired  laval  a/ 

} 

return  naw  base) 

> 


e.wrapO 

( 

free (stack))  I a  restore  stack  space  a/ 

) 
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(include  'synde.h* 


/HHIHHHHHiHIMHHKHIHHIHIIHIMHHHimHHIMHHHI/ 
/*  */ 

/*  atreq  -  test  strings  (or  equality  •/ 

/•  ♦/ 


streq(strl,str2)  /sstring  equality  test  *1 

char  atrltl,  str2Cl| 

{ 

return  < ! streaq (str 1 , str2) ) I 

) 

/HtHHHIMHHfHUHHHIIIMMHIHMIHimHHHIHHHHHHt/ 
/•  */ 

/»  preatr  -  teat  if  itri  it  beginning  of  str2  » / 

/•  t/ 

/§HWmUHIHHHHWWIH#WIWIWIHHHW«UHWHWHHHHW/ 

prestr ( atr 1 , atr 2)  /*  teat  if  atrl  ia  beginning  of  atr2  #/ 

char  atrll],  atr2U|  /•  return  1  if  true,  0  otheruiie  •/ 

{ 

int  i| 
i«0| 

uhilelatrim  -  atr2Cil) 
if  (atrlti^l  -  01 
return  <1M 
if  (atrlCil  «  0) 
return(l)! 
elae  return (0) | 

> 


/•  •/ 

/•  ianueeric  -  teat  if  a  character  ia  a  nuaher  •/ 

/*  »/ 


ltmiaericinua,  aai)  /•  nuaeric  »et  teat  •/ 
char  nuel 
int  aai) 

{ 

return  iadigitinua)  II  i  (nun  -  ’O’M  aaiM 

) 
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taopper(ch)  /•  convert  lowr  cate  character  to  upper  cate  •/ 

lit  dll  /*  return  <11  other*  uModified  •/ 

( 

return  (Ulwar(di)  ?  (chl-V*'A’  :  edit 

) 


tolouer(ch)  /•  convert  upper  cite  character  to  loeer  cite  */ 

lot  dll  /<  return  all  other*  uneodified  */ 

1 

roturo  Meupperlch)  ?  tch)-,A,*'a’  :  ch)| 

) 


iaerr(fp)  /*  hoput  ioorr  function  •/ 

lot  *fp| 

( 

putt (‘I/O  error  occured*)! 

) 
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HHHHHHHHtHItHIH/ 

♦/ 


/m**«m«*t*m«**mm***«tttt*t*l< 

/* 

/♦  dear.finfo  -  clear  file.info  block  »/ 

/»  •/ 
/IHHHHMIHMHHIHItHHHHMHlHIlKIHtHHHHIHmiHK/ 


clear.finfo(fptr)  /*  dear  fiie.info  block  */ 

struct  file  into  *fptr) 

(  int  i; 

fptr-W.buf  ■  Ol 
strcpy (fptr->f_ni»e, 'Ml 
strcpy  <fptr->f.lang,  'Ml 
itrcpy  <  fptr-)f.creat ,  •• )  j 
strcpy<fptr->f_last,"M 
strcpy  ( f ptr->f .conf , '  M  J 
fptr->f_edit  ■  05 
fptr->f .update  ■  0| 
fptr->f_ avail  ■  Oj 
fptr->f.root  «  01 
fptr-)f  dip  ■  01 
for  (1«0|  K101 
fptr-M  aarkti]  ■  0) 

> 


/#  »/ 
/*  cl  tar  _a it  -  dear  ast.node  */ 

/•  '  '  §/ 
/iHHHWWHIMMMIHHIHIHIHHHIHiWmmmiHWHHm/ 


dtar.aftla»t.ptr) 
struct  ast.node  sast.ptrl 
t 

ast_ptr->s.fliQs  «  0i 
ast_ptr->a.value  ■  0| 
ast.ptr->a.prod  ■  01 
ast.ptr->a.right  ■  0l 
ast_ptr->a.son  ■  01 

> 


J*  dear  ast.node 


#/ 
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/» 

/•  cltar.tinfo  -  dear  tcrainal  information  itructur* 
/# 


eltar.tinloltdf.ptr)  /•  cltar  tar a. info 

•tract  ttra  info  *tdf  ptrf 
{  int  U 

tdf.ptr->lin«  ■  0| 
tdf.ptr->char*  ■  OS 
tdf.ptr~>«siza  «  Oj 
tdf_ptr->xxxtll  ■  01 
tdf.ptr->xxx[21  «  OS 
tdf.ptr->xxx(31  ■  01 
tdf_ptr->xxxC4)  «  OS 
tdf.ptr->xxxt51  «  0} 
for*(i«0j  i<29( 
strcpy(tdf.ptr->ctdi[i]l**)| 

•trepy(tdf_ptr->init,*,)S 
•trcpy (tdf _ptr->tab,  **)  S 
•trcpy (tdf .ptr->tl idt, **) S 
•trcpy  (tdf  .ptr-Mi  v,  •  * )  J 
itrepy(tdf.ptr->clr,,,)j 
•trcpy  (tdf  _ptr->po*,,,M 
strcpy  <tdf_ptr->«ol , •“) J 
•trcpy(tdf_ptr->dcf  "U 
•trcpy ( tdf _ptr->r tv, * " ) J 
•trcpy (tdf _ptr->norn, ••) } 

*trcpy(tdf_ptr->ioof "•) I 
•trcpy (tdf  ptr->ioff,*')S 
•trcpy ( tdf _ptr->i 1 , *  * ) I 
•trcpy (tdf _ptr->dl , ■' ) S 
•trcpy (tdf  ptr->finif ••) I 

) 
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/444444444444444444444444444444444444444444S44444444444444  .4444444444/ 
/#  •/ 
/»  ADA1  CODE  LISTER  <c)  Copyright  Novmbor  1903  «/ 
/i  CART.  Hichael  L.  HcCricktn,  USAF.AfIT  SCS-83D  •/ 
It  •/ 
/*  CODE. LISTER  •/ 
I*  •/ 
/•  Raid  coda  fila  generated  by  tha  Adal  eoapilar  and  produca  a  •/ 
It  fornatted  fila  of  tha  coda  for  mar  impaction.  •/ 
It  ti 


/44HII4444HHHHH«H>Ht4HII4<HiHIHHHfHH>H<M4HNH<4H444/ 

•includa  ‘coda.h*  It  piaudo-coda  itructurci  */ 

Idafina  ERROR  -1 
(define  READ  0 

(define  RES  int 


struct 

coda.aord  coda) 

It  pseudo-code  seaory 

4/ 

int 

inst_ptr, 

It  instruction  pointer 

4/ 

code.fi la) 

It  listing  fila  pointer 

4/ 

char 

code.naa*I203, 

/•  output  file  naaa 

4/ 

acodesC  MQP1, 

It  instruction  naan 

4/ 

itrUOU 

1*  display  line  to  build 

4/ 
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/IHMHHHHHHmHIHHHtHHHHtMmHiHIHtHWHHHMIl/ 


/»  */ 

/*  Min  1/ 

/•  Entry  point  and  driver  for  code  litter.  «/ 

/•  •/ 

/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeemeeeteeeeeeeeeeeeeeeeeeeeeeeee/ 

oain(argc,argv) 

int  trqc?  /«  input  argument  count  */ 

cher  *argvC]J  /*  input  arguoent  ptri  ♦/ 


{ 

putt ('COPE  LISTED  11/11/83')? 

if  Urge  <  2)  *  prepare  source  file  naoe  */ 

{ 

putiCUntpKified  source  file.')? 
exit?)? 

) 

c.inito? 
if  Urge  >  2) 

ttrepy  (code  jiue,  irgvC2I)  f 

cite 

{ 

putiC  Fileniee  for  code  listing?  (default  it  naoe.codltt)*)| 

gets (code  naoe)? 

putt(")| 

if  (!ttrlen(code  naoe)) 

( 

ttrepy  (code .naoe,  argvl  ID? 
itrcattcode  naee,'.codlst')| 

) 

) 

printfCCode  list  output  file  ■  Xi.',code_nue); 

if  ((code.file  ■  creat(code  naee,M44))  »■  ERROR) 

{ 

put si* Cannot  create  code  listing  file.')? 
exitO? 

) 

else 

c.litt(argv(l))| 
cloteUode.fi  le)  | 

) 
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/HHHHiHmHHIWHOmittitHItHHtHOitMmmHHMtHW/ 
/*  */ 
/*  c.init  *  initialize  codes  array  eith  instruction  strings.  » / 
/♦  *  »/ 

/tHHIItHIHiHttHKHiHitmHHHflHHIKKitilHtttHHtitHI/ 

e.init!) 


codest.JHP] 

•  ‘JHP‘| 

codest.CPY] 

.  ‘CPY‘1 

codes!.ST01 

»  *ST0*( 

codes!. CALI 

»  ‘CALM 

codes!  JPC1 

»  ‘JPC‘1 

codes!  JBU] 

.  *EflU‘J 

codes t.MEfl] 

■  *NEQ‘( 

codes!. LES1 

■  *LES‘> 

codes!  LEB3 

«  ‘LEQ‘1 

codesl'sRT] 

«  ‘SRT'J 

codes!  6EQ] 

»  ‘6EO*5 

codesI.NESl 

»  ‘NE6‘» 

codest.ADD] 

*  ‘ADO*! 

codesI.SUB] 

«  *SUB‘i 

codes!  "dUU 

•  ‘HUL‘J 

codes!*D!V] 

•  ‘OIVj 

codesI.LIT] 

»  ‘LIT‘1 

codest.LODl 

-  ‘L0D*1 

codes! .RET] 

»  ‘RETM 

codes!. AND] 

»  "AND'l 

codes!  OR] 

»  ‘0R*| 

codes!~N0T] 

-  ‘NOT‘1 

codes! .DCS] 

■  ‘DCS‘1 

codes!  HOD! 

•  ‘HOD‘1 

codes! ~REW) 

«  ‘REN‘1 

codes!  AND  THEN]-  ‘AND  THEN' 

codes! .OR  ELSE]  *  ‘OR  ELSE'l 

codes! _X0R] 

■  ‘TOR'I 

codes!  ABS] 

»  ‘ABB'I 

codest.EIP] 

«  ‘EIP'J 

codes!  NOOP] 

»  'NOOP‘5 

) 


/•  instruction  nates  */ 
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/WHHHIHHIHHHIHmillHHHHtlHtilHHHHIHHHHHilfi/ 
/*  */ 

/*  c.list  -  product  codt  listing  tnd  output  to  a  file  #/ 

/*  *1 

/IHHIHWHHHiliHHHHIlHIHtHtlHHHiliHIHHHHHIlHHI/ 


c.list  ic.natt) 
char  c.natt£l| 


{ 

i nt  c.f i 1 t, nus.rtad , i nstr .nut, i , cont I 
char  str[401j 

i nstr .nut  *  0} 

strcat(c.naat,'.cod'): 

if  He  filt  ■  optnic  nut, READ))  ■■  ERROR) 

( 

puts<BI/0  error  optning  codt  filt  •){ 

putsic.naat); 

puts(V)) 

) 

tlst 

(  /a  rtad  until  tnd  of  filt  */ 

nhilt  (nut.raad  ■  rtad(c_filt,lcodi, isirtof (struct  codt. word) I) 

II  cont) 

< 

if  (nua.rtad  •»  ERROR) 
puts('I/0  trror  rtading  codt  fill.*)) 

tlst 

( 


strcpy<str(aa) | 

/•  initializi  as  tspty 

*/ 

cat nua (str , i nstr .nut++ ) | 

•treat (str, a  :  *)| 

if  <(i  >  codt.c.opcodt)  >  0) 

{ 

strcat(str,codistil)i 

/•  instruction  nutbtr 

t/ 

/•  instruction  string 

»/ 

streattstr,"  •)) 
catnut(str,codt.c_opl)| 
streatistr,*,*))  * 

/•  optrand  1 

»/ 

catnuatstr , codt. c.op2) ( 

> 

tlst 

/•  optrand  2 

*/ 

if  (i  ~  0) 

/•  tnd  of  filt  btfon 

♦/ 

/•  actual  filt  tnd 

•/ 

{ 

strcpyUtr,M)| 
cont  ■  0| 

) 

tlst 

•treat (str, ’INVALID”) |  /•  invalid  instruction  •/ 

strcat(str,,a)| 
i  *  strltn(str)) 
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if  (erite(eode.file,*tr,i)  !«  i) 
putil‘I/0  error  uriting  cod*  lilting  file.*)! 

) 

> 

1 

dottle  filell 

) 


/» 

/• 

/* 

/• 

/* 


citnu* 


ConcatMit*  til*  ASCII  rtpriuntation  of  a  ligntd 
maker  to  the  end  of  th*  giv*n  itring. 


lf*#**IIM/ 
*/ 
*/ 
#/ 
♦/ 
*/ 


catnu*(itring,val) 


char 

Htrinqi 

int 

vail 

char 

i(71| 

REB 

ii 

if  ival  <  0)  { 

•treat (itring, *-•)} 
val  •  -vail 
) 

■Ci  «  61  •  01 
do  ( 

si — il  «  val  X  10  ♦  'O’j 
)  uhile  (val  ■  val  /  10) ( 
•trcat(itrinq,to(il)f 
) 


/•  temporary  itring  */ 

I*  itring  ind*i  t/ 

/•  negative  value  */ 

/•  generate  character!  in  t/ 
/i  revKM  order  */ 


/•  concatenate  nuaber  itring*/ 


198 


Figure  G-6  Procedure  Call  Analyzer 


VITA 


VITA 

Michael  L.  McCracken  was  born  on  25  July  1952  in  Glen 
Ridge,  New  Jersey  to  Robert  A.  McCracken  and  Lilian  B. 
(Sarter)  McCracken.  He  attended  Sehome  High  School  in 
Bellingham,  Washington  and  graduated  cum  laude  in  1970. 
He  attended  Western  Washington  State  College  in 
Bellingham,  Washington  where  he  earned  a  Bachelors  of  Arts 
degree  in  mathematics  in  June  1977.  In  July  1978  he 
entered  Officer's  Training  School  at  Medina  Annex, 
Lackland  Air  Force  Base  and  was  commissioned  in  October. 
His  first  active  duty  Air  Force  assignment  was  with  the 
2nd  Communications  Squadron  which  later  became  Detachment 
1  4602  CPUSS  at  Lowry  AFB ,  Colorado.  He  then  entered  the 

Air  Force  Institute  of  Technology  in  June  1982  as  a 
graduate  student  in  computer  science. 

Captain  McCracken  was  married  to  Kerri  Lee  Lobberegt 
on  15  May  1976  in  Port  Gamble,  Washington.  They  have  a 
daughter,  April  Lynn,  born  25  February  1980  and  a  son, 
Patrick  Logan,  born  12  December  1981. 

Permanent  address:  5191  N.E.  Ponderosa  Drive 

Hansville,  Washington  98340 


UNCLASSIFIED 


security  classification  of  this  page 


tyHMlL  Q2H 


REPORT  DOCUMENTATION  PAGE 


REPORT  SECURITY  CLASSIFICATION 

UNCLASSIFIED 


lb.  RESTRICTIVE  MARKINGS 


2a.  security  classification  authority 


2b.  oeclassification/oowngraoing  schedule 


3.  OlSTR  I  but  ion/availability  of  report 

Aptfflov*#  PuDUc  rL’tcfcflSt 

'tosidl  ftolUw 


4.  PERFORMING  ORGANIZATION  REPORT  NUMBER(S) 

AFIT/  GCS/IIA/  33D-4 


5.  MONITORING  ORGANIZATION  REPORT  NUMBER(S) 


NAME  OF  PERFORMING  ORGANIZATION 

School  of  Engineering 


|6b.  OFFICE  SYMBOL 
(If  applicable) 


7«.  NAME  OF  MONITORING  ORGANIZATION 


AFIT/ENG 


6c.  AOORESS  {City.  SUM  and  ZIP  Coda) 


7b.  AOORESS  (City,  Stott  and  ZIP  Code) 


Air  Force  Institute  of  Technology 
Wright  Patterson  AFB,  Ohio  45433 


■a.  NAME  OF  FUNOING/SPONSORING 

organization 


|8b.  OFFICE  SYMBOL 
(If  applicable) 


9 .  PROCUREMENT  INSTRUMENT  IDENTIFICATION  NUMBER 


8c.  AOORESS  (City,  State  and  ZIP  Code) 


10.  SOURCE  OF  FUNDING  NOS. 


PROGRAM 

PROJECT 

TASK 

WORK  UNIT 

ELEMENT  NO. 

NO. 

NO. 

NO. 

11.  TITLE  (Include  Security  Classification) 

See  Box  19 

12.  PERSONAL  AUTHORIS) 

Michael  L.  McCracken,  B.A. ,  Capt.  I’SAF 


j  14.  OATE  OF  REPORT  ( Yr ..  Mo..  Day) 

•  I  IPG 3  Dp.ceTr.ber  5 _ 


13a.  TYPE  OF  REPORT 

MS  Thesis 


13b.  TIME  COVERED 
FROM _  TO. 


IS.  PAGE  COUNT 

214 


16.  SUPPLEMENTARY  NOTATION 


AparevcJ  for.paLLc  re!.- .-e:  IS  I?  130  17 

v.’Clav!  r> 


17. 

COSATI  COOES 

18.  SUBJECT  TERMS  (Continue  on  reverse  if  nAeedsen^alsd '141dm WV  byJHoeMndmtiiti 

FIELD 

GROUP 

SUB.  GR. 

y/tighX-Fatoatsca  Aid  CU  Lilj 

09 

02 

18.  ABSTRACT  (Continue  on  reverse  if  necessary  and  identify  by  block  number) 

Title:  ADAl  -  AN  ADA  SUBSET  COMPILER  FOR  THE  AFIT  SYNTAX 
DIRECTED  PROGRAMMING  ENVIRONMENT 


Thesis  Advisor:  Capt  Patricia  K.  Lawlls 


IzO.  OI8TRIBUTION/AVAILA8ILITY  OF  ABSTRACT 

21.  ABSTRACT  SECURITY  CLASSIFICATION  1 

aUNCLASSIFICO/UNUMITEO  9  SAME  AS  RFT.  □  OTIC  USERS  □ 

UNCLASSIFIED 

1 22a.  NAME  OF  RESPONSIBLE  INOIVIOUAL 

22b.  TELEPHONE  NUMBER 

1 Include  Area  Coda) 

22c.  OFFICE  SYMBOL 

|  Capt  Patricia  K.  Lawlis 

(513)  255-3636 

AFIT/ENC 

00  FORM  1473, 83  APR 


BOITION  OP  1  JAN  73  IS  OBSOLETE. 


UNCLASSIFIED 


sscurity  classification  of  THIS  FAQ* 


B 


SECURITY  classification  of  this  page 


Abstract 


This  docurrent  describes  the  effort  involved  in 
moving  the  AdaO  compiler  and  interpreter  developed  by 
Capt.  Scott  E.  Ferguson  as  part  of  the  AFIT  syntax 
directed  editor  environment  from  a  microcomputer  to  the 
VAX  11/780. 

As  part  of  this  effort  the  compiler  and 
interpreter  were  expanded  to  accept  a  larger  suset  of 
Ada.  The  compiler  and  interpreter  work  with  an 
abstract  syntax  representation  of  a  computer  program 
produced  by  the  syntax  directed  editor.  This  abstract 
representation,  which  is  guaranteed  to  be  syntactically 
correct,  makes  the  compiler  much  easier  to  write  and 
understand.  The  compiler  in  a  top-down  compiler  but  no 
backtracking  is  needed  since  the  program  is  known  to  be 
syntactically  correct.  The  interpreter  is  able  to  use 
the  abstract  representation  to  give  the  user  an 
interactive  display  of  the  program  during  execution. 

Designs  to  allow  overloading  of  names  and 
operators,  and  passing  parameters  to  subprograms  are 
also  presented. 


T 


AD-A138  027  AOA 1 :  AN  ADA  SUBSET  COMPILER  FOR  THE  AFIT  SYNTAX  «  4./ 

DIRECTED  PROGRAMMING  ENV..IUI  AIR  FORCE  INST  OF  TECH 
WR I GHT - PATTERSON  AFB  OH  SCHOOL  OF  ENGI  M  L  MCCRATKFN 
UNC1ASSIFIED  05  DEC  83  AFIT/GCS/MA/83D-4  F/G  9/2  NL 


re^rv:. 


I 


